[uClibc] Autoconfiscating uClibc

[Carl Miller]

> > I was wondering how much effort would take to add
> > autoconf support to the uClibc build infrastructure.
> > 
> > I don't think uClibc itself would benefit much from
> > this change.  The kernel KBuild infrastructure is up
> > to the task and very convenient for the user.
> 
> We definitely don't want to use autoconf.  But...
> 
> > However, autoconfiscation would make it easy
> > to integrate uClibc into GCC's uberbaum build
> > machinery in place of newlib.
> > 
> > Building an uClibc based toolchain in a single step
> > without a complex external script would be a very
> > desiderable feature.
> 
> Agreed, and it is something I've thought about off and on.  Adding a
> "configure" script should be easy enough to do.  So the bulk of the
> work would probably be making the uClibc build system respect VPATH.
> 
> > If somebody wants to do the uClibc related work,
> > I'll do the required changes in GCC's top-level
> > configure and automake and push patches into
> > GCC's repository.
> 
> 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
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.

I wonder, if that was your worst objection to this patch, why did you not
raise it earlier?  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.

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.

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.


                          ------Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc-makefiles.patch.gz
Type: application/octet-stream
Size: 18464 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20040529/f9a6349f/attachment.obj