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

[Mark Mitchell <mark at codesourcery dot com>]

Nick Clifton wrote:
> Hi Mark,
> 
>> I continue to believe that incorporating these libraries into our tree
>> is a bad idea, and that even including machinery to use in-tree copies
>> is a bad idea, 
> 
> Why is it a bad idea ?  Is it the "funny options and DejaGNU goo" that
> you referred to or is there some other reason why you do not like it ?

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.

I definitely confused the situation by using the term "stand-alone".  I
meant it to mean "should include the compiler and nothing more", rather
than "should contain everything you need to link into GCC".

I don't like pulling these libraries in-tree for several reasons:

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".

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.

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.
  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.

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.

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. :-)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713