Le Thu, Dec 14, 2006 at 07:29:19AM -0800, Ian Lance Taylor écrivait/wrote: > Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > > > This makes life much simpler to me, but then I do not understand how end- > > users compiling GCC are expected to configure it. Does this mean that the > > instructions on http://gcc.gnu.org/install/configure.html are no more valid > > for that case? > > 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. 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? > 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? > > > 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! -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
