Re: PATCH to pre-select languages to be build

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Wed, 30 September 1998, 03:19:22, law@cygnus.com wrote:

 > 
 [snip]
 > 
 >   In message <13840.57066.10628.804866@slsvhmt>you write:
 >   > 
 >   > The  approach you were talking about  assumes,  everybody who wants to
 >   > restrict the languages to a particular subset
 >   > 
 >   >   - knows which languages do exist and which do I want.
 >   > 
 >   > My patch below goes the other way round. It's  based on the assumption
 >   > that most people
 >   > 
 >   >   - know which languages they actually want to build.
 >   > 
 >   > If the "--disable-chill"  would have been  available before the recent
 >   > languages had been introduced, all users, that only  wanted "c c++" to
 >   > be  built, would  still  get the  new  compilers,  simply because they
 >   > didn't know such a beast exists.
 > I think there's a much simpler way to do this.  Something like this in gcc/configure.in
 > # Figure out what language subdirectories are present.
 [script removed]
 > 
 > This is what we're using inside Cygnus to disable fortran & objc.  It's easily
 > extended to handle additional languages and to support a full enable/disable
 > syntax.
 > 
 > We then have the associated runtime libraries automatically disable themselves
 > if the proper compiler isn't found in <objdir>/gcc.  This should be fairly
 > simple too, though we haven't actually tried it.
 > 
 > jeff
 > 
 > 

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 :-(

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.

  $ configure --disable-f77 --disable-objc
  $ make LANGUAGES="c c++" bootstrap install

ending up with  two unwanted compilers installed  (CHILL and Java); he
simply wasn't aware of their existance.

Although the changes to the toplevel Makefile.in might look ugly, they
are completely transparent to the user.

manfred