This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: configuration options policy (at toplevel or only inside gcc/)?
Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
> Le Thu, Dec 14, 2006 at 07:29:19AM -0800, Ian Lance Taylor Ãcrivait/wrote:
>
> > 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.
I just ran the top level configure script with --with-foobar, and then
did "make configure-gcc". When I look in gcc/config.status I do see
--with-foobar in there. So I think it does work as I expected. I
haven't bothered to dig into exactly how it works.
> > 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, definitely not. That would not be acceptable.
> > > 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!
I don't think it has been firmly decided to not permit the user to
unpack MPFR and GMP next to gcc, and have that work--the traditional
one-tree build.
Ian