PATCH to pre-select languages to be build

Manfred Hollstein manfred@s-direktnet.de
Wed Sep 30 08:07:00 GMT 1998


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



More information about the Gcc mailing list