This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA/RFC: Adding support for gmp and mpfr sources in the build tree
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