RFA/RFC: Adding support for gmp and mpfr sources in the build tree

Nick Clifton nickc@redhat.com
Tue Nov 28 16:35:00 GMT 2006


Hi Mark,

> Let me make clear once again that I'm not saying "we shall not do this".
> I'm arguing against it, but I'm not blocking it.

That's fine.  I am not saying that it must be done either.  I am just 
trying to ascertain your reasons and seeing if I agree with them, or if 
I think that their might be an alternative.

(Incidentally it seems to me that a lot of the desire for this patch to 
support gmp and mpfr in-tree could have been reduced if the change to 
make them requirements for a gcc build had been delayed until there were 
a lot more installations out there with the required versions of gmp and 
mpfr already installed.  But there you go).

> 1. They're not our area of expertise.  GMP and MPFR are specialized
> libraries, written by third parties who know how they work.  We
> shouldn't need to know how they work; to me, this is essentially "system
> software" like "printf".

Agreed.  I think that the only reason for ever pulling such libraries 
into the official source tree would be if development/maintainance of 
them ever ceased and an alternative was not available.

> 2. They make the tree bigger, but we can't modify these libraries
> in-tree per FSF policy.  (Joseph is frustrated right now by this policy,
> since it's blocking soft-float progress, but it is the policy, whether
> we like it or not.)  So, putting this code in the tree is equivalent to
> having a tarball on our web site of a known-good GMP/MPFR, but more
> dangerous, in that we might forget the policy and change stuff.

Just a thought - with subversion is it possible to have a URL as a 
placeholder for a directory ?  So that for example the gmp sources could 
be included in the gcc source tree as a URL to the real gmp sources. 
Check outs would go to the gmp site and fetch the latest sources from 
there (as an anonymous read), and check-ins would fail because of lack 
of write-permission.  (Thus reminding the checker-in that they need to 
submit a separate patch).

> 3. It adds build-system complexity.  We know we need to be able to use a
> system GMP/MPFR, since that's what distributors are going to want to do.

Except that, at the moment, most systems do not have a sufficiently 
up-to-date installation of MPFR, making the installation of gcc problematic.

>   The installation layout of the library is presumably less variable
> than the build-time layout of the library, so without a staged
> installation, we are likely to gradually grow version checks for
> particular versions of GMP to handle particular include files and
> libraries.  I think that, without staged installation, you'd have to put
> back the option that we just took out -- and which everyone seemed happy
> to remove.

Maybe they did not realize the full consequences of removing the 
option... :-)  But I agree, a staged installation would be a much nicer 
solution.

> 4. I think the funny options and DejaGNU goo are a problem.  In general,
> our build system is much more complicated because we don't actually
> install anything.  The libstdc++ makefiles have to poke about to find
> the compiler, and running the testsuites involves lots of extra library
> paths, and so forth.  That means we're not testing the tools in the way
> that users use them, and it means that our build system has a lot more
> stuff in it than it needs to have.  I don't want to add to that complexity.

Agreed - it would be very nice if we could remove all of that gunk.

> Now, I understand that Red Hat has always used the in-tree build
> process, and there are  many current and former Cyg-Hatters out there,
> and that my opinions probably don't reflect consensus.  So, I've put my
> opinion on the record, and now I'll just back away slowly. :-)

Heh :-)  I do not mind if the patch is not accepted into the tree.  Red 
Hat is perfectly able to maintain a set of extra patched on top of the 
official sources, and if that includes supporting gmp and mpfr in-tree 
then so be it.  I actually think that submitting this patch has already 
achieved two things:

   * Documented a way that the gmp and mpfr sources can be included in
     the source tree if a person or organisation wishes to do so (and
     they are prepared to patch the gcc sources).

   * Pointed out the real need for a staged installation approach.
     I will look at this in my copious free time(tm). :-)

Cheers
   Nick



More information about the Gcc-patches mailing list