[RFC] build system replacement

[Peter Kjellerstedt]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernhard Fischer
> Sent: den 3 juni 2008 10:29
> To: Bernd Schmidt
> Cc: uClibc
> Subject: Re: [RFC] build system replacement
>
> On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote:
> > Bernhard Fischer wrote:
> >> I hope i improved the situation a bit now (if you use
> >> r22158 and later).  We honour both all our prerequisites
> >> (if your compiler groks what we mean to ask for in our
> >> gcc-ism) as well as the used CC and flags.  I consider
> >> this fixed, issue closed, nothing to see here, please move
> >> on (or holler if i broke something) :)
> >
> > I've done a bit of digging, and found the cause of two
> > problems.
> >
> > 1. So far, only libc-so-y and libc-a-y are tracked.
> > This needs to be extended to handle all the other
> > libraries, including ld.so.
> >
> > 2. The CFLAGS passed to the compiler have changed in some
> > cases.  Previously, when compiling ldso/libdl/libdl.c,  $^
> > used to be "ldso/libdl/libdl.c"; it is now
> > "ldso/libdl/libdl.c FORCE", which means that
> > $(CFLAGS-$(notdir $(^D)) no longer does the right thing:
> > $(notdir $(^D)) is now "libdl .".
> >
> > There's also $(CFLAGS-$(notdir $<)) in the command line,
> > which doesn't work for this case, since it expands to
> > "ldso/libdl/"; note the prefix "ldso/" and the trailing slash.
> >
> > We could fix this by using $(<D) instead of $(^D) in the
> > above.  Also, maybe it makes sense to clean up the CFLAGS to
> > always mention the full path without trailing slash.
>
> I see that you already took care of this, many thanks.
>
> We still have a problem, though. Consider HAVE_SHARED set
> (i.e. ldso is built) and also some thread variant selected.
> Build. Turn off thread-support. make clean && make; bummer.
>
> Suddently there is no rule to make include/bits/pthreadtypes.h
> (anymore).  We recorded this header as a prereq in the first
> build, but of course turning off thread-support breaks this
> horribly. A make realclean obviously would bypass this, but
> either we need dummy-rules for conditional headers like this
> or do something else to drop those now unavailable prerequisites.

Something along what gcc's -MP option does?

> I'll think about this some more, but perhaps somebody has an
> opinion or an idea..  :)

//Peter