This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc: cleaning up top level config

Alex Rosenberg wrote:
on 11/10/02 9:35 PM, Stan Shebs at wrote:

Zack Weinberg wrote:

On Sun, Nov 10, 2002 at 01:16:25PM -0800, Stan Shebs wrote:

Zack Weinberg wrote:

There's also a bunch of nonfunctional MPW support code in libiberty,
and there might be some lurking in other subdirectories.  I'm
definitely in favor of removing all of it.  However, the last time
this was proposed, some enthusiasts popped up and squelched the idea.

There was some interest in retaining the source code bits, but not
the configury.  I might even have received a proposed patch
recently, need to check my mbox.

I don't see why we should keep the source code around if it can't be
configured; all it does is clutter up the tree.  It can always be dug
out of CVS or a previous release tarball if anyone really does care.

The patch in question had a different way of configuring/building I
think.  The whole mpw-configure process was based on sed'ing Unix
makefiles and shell scripts into MPW syntax (which was similar to
Unix but randomly different), but certainly it's not the only way
to do things.  Practically speaking, the source code is probably dead
too, but it won't hurt anything to take another day or two to make

I submitted a patch and there was a collective yawn.


The only feedback I got about my patch was a discussion of why the C++
front-end is allowed to be written with GCC-specific extensions. Of course,
this didn't help me, since I'm not interested in porting GCC to target the
MPW host; I only use MPW as a cross-host.

Indeed, I do not use the normal autoconf/make build system since that
doesn't work in non-Unix platforms. Stan's method of using sed to convert
that build system for MPW was less maintainable than simply building new
makefiles directly in MPW's make syntax. Removing the stub bits of Stan's
MPW build system wouldn't bother me.

Think about this for a second: "I don't have an x86 GNU/Linux box. Therefore
I propose that it should be deprecated as soon as possible." Does that upset
you? Good. I'm upset that here we are a year after I submitted a patch to
fix things and without even exploring the contents of the patch you're once
again proposing to remove the code. This community is very difficult to
collaborate with; I'm not sure why I bothered to build a patch. Do you
Mmm. I concluded that the only way to get a patch in is to remind people about it at least once a month (which is in fact recommended somewhere). I think everyone just has really really bad memories.

If I could approve your patch, I would, but I can't.

people even realize what a PITA it is to produce diff output in MPW? How
Maybe this is why so few people use MPW these days. :-/

about the fact that MPW is built around the microcomputer concept that an
indent level is always equal to a tab, yet ya'll are still stuck with 8
character tabs thanks to some dumb terminal nobody can even name anymore and
you have rigid formatting rules that pretty much require the use of emacs?
Um. I can't actually find anything about 8-character tabs in coding standards. The de facto standard seems to be to not use tabs at all, just space indents, with two-space indents and four-space indents depending on circumstances. (And funny indents for long expressions, but the microcomputer standard was to keep those on one line.) You could probably whip up a tabify/untabify tool which replaced each pair of leading spaces with a tab and vice versa. (Note that section 23 in GNU coding standards is mostly recommended, not required.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]