[uClibc] Autoconfiscating uClibc

[Manuel Novoa III]

Hello,

On Sat, May 29, 2004 at 05:13:27PM -0700, Carl Miller wrote:
> > Regretably, neither Erik or I have had any significant amount of time
> > for uClibc development in what seems like months.  And the only patch
> > I've seen (maybe a year ago) towards integrating uClibc in gcc's
> > build system added a configure script that actually copied the entire
> > uClibc source tree to the build dir.
> 
> Manuel, are you maybe talking about this patch (attached)?
> 
> If so, I don't think you took a very close look at it.  I most definitely

Quite possibly.  Looking back at the archives, you initially posted
in around mid December.  With other projects and all the holiday
goings-on, I probably just glanced at it.

> do not copy the entire source tree to the build dir.  I make a parallel
> set of directories, but do not populate them with source files.  In this
> respect, it works very much like a regular autoconf configure script.
> The one thing I do copy wholesale is the include directory.  That's
> because I found it easiest to have everything that's an installable
> target resident in the build directory (admittedly a bit of laziness on
> my part; with some more work, I could probably work around that issue).
> For a C library, the entire set of header files are themselves installable
> targets.

My apologies for the misinformation.

Need to think about the include directory issue.

> I wonder, if that was your worst objection to this patch, why did you not
> raise it earlier?

Because both Erik and I had a bunch of other things going on?  As I
recall, we were running lots of tests on various archs, releasing
rootfs images, doing "holiday stuff", etc.

>                    I've never heard that particular objection before. I
> have heard two other objections, which are well-founded:
> 
> 1) This patch is against the 0.9.23 release, which is quite old.
>   Yes, it is.  0.9.23 was the most current release when I began working
>   on this, and I haven't bothered to update the patch to more recent
>   releases or to the current CVS.  That's largely due to the fact that I
>   got very little positive feedback about this patch, and got the
>   impression that even if I did rework it to apply cleanly to current
>   sources, nobody would use it.  If that impression is wrong, let me know,
>   and I think I could be fairly easily convinced to freshen it up.

Probably not a big problem, as I don't remember things changing all that
much.

> 2) It uses Perl.  Several people were trying to build uClibc in very
>    minimal environments in which Perl was not available.
>   I hadn't thought of that when I created this patch, but that's a very
>   good point.  I've since put a little thought into how I could do the
>   same job without Perl, but haven't taken any action on it yet.  Largely
>   the same reasons as in #1 above, but also I think it might turn out to
>   be significantly more work than addressing issue #1, and I have limited
>   time to devote to this.

Yeah... the perl dependency is more of a problem.

> But that it's lame because it copies the entire source tree?  I agree,
> that would be lame, but the allegation is provably false.  I could see an
> objection to copying the entire set of header files, as I thought that was
> less than perfectly clean myself, but that's a "lameness infraction" an
> order of magnitude or two smaller than the one charged.  And given some
> positive feedback, I might be encouraged to address that issue as well.

Apologies again.  Like I said though... was a busy time of the year.
This isn't the only thing that slipped through.  I think I recall that
we overlooked the whole frv port as well.

Manuel