Re: gcc: cleaning up top level config

[Nathanael Nerode <neroden at twcny dot rr dot com>]

Alex Rosenberg wrote:
> on 11/10/02 9:35 PM, Stan Shebs at shebs@apple.com 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
> > sure.
>
> I submitted a patch and there was a collective yawn.
>
> <http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01444.html>
>
> 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?
> Feh. 
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.)