PATCH to pre-select languages to be build

[Manfred Hollstein]

On Wed, 30 September 1998, 13:14:00, law@cygnus.com wrote:

 > 
 >   In message <13842.2446.855496.247677@slsvhmt>you write:
 >   > Well, I could  implement this in  addition, too. But there's a problem
 >   > with this approach: let's suppose  Craig wants to  build the C and the
 >   > F77 (only! no c++ ...) compilers, hence he wants to disable c++ (note,
 >   > this name is used for $(LANGUAGES)!);  thus he adds `--disable-c++' to
 >   > his configure command. I guess you know the result:
 >   > 
 >   > >From the toplevel configure file:
 >   > 
 >   >   sh: enable_c++=no: command not found
 >   > 
 >   > and inside the gcc subdirectory:
 >   > 
 >   >   configure: error: c++: invalid feature name
 >   > 
 >   > This is caused by `c++' not being a  valid shell variable name. OK, we
 >   > can hack our toplevel configure script replacing  '+' with 'x', but we
 >   > would have to do this  for autoconf, too, and  I believe this might be
 >   > hard to get a  fixed autoconf in  time... .  Another solution might be
 >   > to use different name, i.e.   `--disable-cxx', but  then we'd have  to
 >   > use "c++" for $(LANGUAGES)    and "cxx" for the   --enable-/--disable-
 >   > stuff :-(
 > Ugh.  I'd almost prefer to replace + with x as needed.  The code is really
 > simpler than your approach.
 > 

I'm  sorry if I  sound  pedantic.  The problem  is   not only  in  our
configure file, this can be changed easily;  I'm seeing major problems
with gcc's (and now libiberty   as well) autoconf generated  configure
file: all of them include code to check, if the  feature to be enabled
or disabled

  "consists only of alphanumeric characters and dashes"

(cited from autoconf.info).

Since  we already have   our own  autoconf-9xmmdd.tar.gz file,  we can
easily setup a  new one with this  fix applied; but,  to be honest,  I
don't actually know  from memory, if the  version I'm using is the one
from /pub/egcs/infrastructure  or  from /private/gas  or perhaps  even
from /private/gdb.

If  we're going the  install  a  patch  in egcs    relying on such   a
particularly fixed  autoconf  version, we  might  end up with "broken"
configure scripts some day, only because  somebody checked in a script
generated by his/her installed default  autoconf version (i.e.  2.12);
and in addition,   we'll have  to  make sure,  these  changes  will be
incorporated into the upcoming 2.13, too.

I'm not opposed   to the --enable-/--disable-  stuff you're proposing,
but my patch works *now and for  all languages*, and it doesn't depend
on fixes to be applied to "foreign" packages.

May I suggest:

  1. We install my patch now; this will cover the "positive" side,
     i.e. the user can specify which languages he *wants* to build.
     (BTW, a similar patch to the toplevel Makefile.in would be
     necessary for your patch, too)
  2. Once we have a fixed autoconf version available and all egcs
     maintainers are aware of it and are using it, we'll be going
     to install the extensions you've suggested for those users,
     that want to specify what they *don't want* to be built.

 >   > My  argument concerning new compilers in   a new tarball still stands,
 >   > too.  The  average test user gets  a new egcs-x.y.tar.gz  file, untars
 >   > it, and calls his usual build script/comand, e.g.
 > By default we should build all languages.  The user must explicitly specify
 > that they do not want particular languages.  I think we've agreed on that.

My patch doesn't change the default.

 > 
 > jeff

manfred