Re: configuration options policy (at toplevel or only inside gcc/)?

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

> > Note that configure options beginning with --with and --enable are
> > passed from the top level configure script to the subdirectory
> > configure scripts.  So the user just uses all the options at the top
> > level, and the subdirectories will see them.
>
> I did notice this, but it seems to me (maybe I am wrong) that there is
> no generic machinery which passes the --with & --enable of the
> top-level configure to the configure in gcc subdirectory. There is
> some code in Makefile.tpl for this, but each such option has to be
> explicitly & individually processed. 

No, see how host_configure_args is set in Makefile.in.

> In other words for adding new configure options to gcc/ subdirectory,
> we have to hack the gcc/configure.ac file, the toplevel configure.in
> and the toplevel Makefile.tpl and this should be done for every
> user-visible options. Otherwise, it is an option which is not visible
> to the user. If I hack only gcc/configure.ac, I am adding an option
> which the user do not see. Is this correct?

No, you are adding an option that will not be listed in ./configure 
--help.  So you document that option in install.texi.

> > I agree that new options should only be added at the appropriate
> > level, but there is one disadvantage: top level configure --help will
> > not display them.  But then configure --help is kind of useless anyhow
> > since it has so much boilerplate, so this is not a significant
> > problem.
>
> Still, what is the build procedure then? Do we expect users to type
> two configure commands?

No.  Options are passed down automatically from the toplevel configure 
to the ones below.  This is true of any configure script, even though 
the gcc/binutils/gdb/cygwin/newlib/... toplevel configure script has 
some extra involutions.

> > > At last I do not understand why the MPFR & GMP stuff which has been
> > > discussed a lot is not already under the above scheme? Why is it cheched at
> > > toplevel and not only in gcc/ ? AFAIK the #include <gmp.h> appears only in
> > > gcc/real.h
> > It's at the top level because the original implementation envisioned
> > support for putting MPFR and GMP in the tree, alongside of the
> > directories gcc, libcpp, etc.  That may still happen.
>
> Thanks for the explanation. But I thought it has been firmly decided
> to keep GMP & MPFR outside!

We might still allow other people to put gmp and mpfr in the same source 
tree as gcc, even though it was decided to keep them out of the gcc tarball.