[RFC] build system replacement
Bernhard Fischer
rep.dot.nop at gmail.com
Sun Jun 1 13:02:20 UTC 2008
On Sat, May 31, 2008 at 05:57:38PM +0200, Denys Vlasenko wrote:
>On Saturday 31 May 2008 13:55, Bernd Schmidt wrote:
>> Denys Vlasenko wrote:
>> > 2. The breakage is not as widespread as I thought - actually,
>> > all .c files are properly tracked. Or almost all -
>> > I did not check all possibilities, maybe there are a few more
>> > obscure .config's with problems.
>> >
>> >> Adding header file dependencies would be a good thing. IMO, if it can
>> >> be done within the existing framework, that's better than throwing
>> >> everything out.
>> >
>> > Are you willing to look into it?
>>
>> I'm not really a make expert, and I didn't intend to become maintainer
>> when I submitted a patch...
>
>Is there a maintainer of it? If not, is anyone willing to become one?
No and i don't think such a thing is really needed.
>
>> The patch below copies over just enough parts of the glibc dependency
>> system to make it work on simple cases in uClibc (tested by touching
>> include/mntent.h and watching it rebuild only five files). It's
>> probably uglier and less efficient than it needs to be; I doubt it
>> tracks all object files, and it doesn't integrate with "make clean".
>
>"compile-mkdep-flags" variable is used exactly in one place.
>It's not clear to the casual reader why you want it to be
>a separate variable.
CC from random vendor may barf on those -MXYZ
It's more obvious to encapsulate it like we did in CFLAGS_gen.dep
>
>+depfiles := ...
>
>A variable with '+' in name? Well, yes, make allows even this,
>but is there a reason for it? Reader gets confused again...
>
>> Finishing the job is left as an exercise for the reader :-)
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) :)
More information about the uClibc
mailing list