[U-Boot] Nested Makefiles

[Albert ARIBAUD]

Le 17/06/2011 02:09, Mike Frysinger a écrit :
> On Thursday, June 16, 2011 18:03:07 Wolfgang Denk wrote:
>> Simon Glass wrote:
>>> Is it possible for U-Boot to use a system similar to Linux from 2.6
>>> where it prints out the full pathname of each file it is building, and
>>> doesn't change in and out of directories as it builds. Perhaps
>>> including the subdirectory Makefiles instead using make -C? I haven't
>>> looked at how Linux does it. Is there some reason U-Boot cannot /
>>> should not do the same?
>>
>> Of course we can have that - if somebody submits patches for it.
>
> this sounds ambiguous ... i think you mean "no, this isnt going into u-boot,
> but people can submit patches to other projects like GNU make".
> -mike

There are two independent issues/topics here, and IIUC, one would 
require patches to U-Boot and the other, patches to make :

1) recursive vs non-recursive makefiles.

These would be U-Boot patches, if any.

I am in favor of 'non-recursive', i.e. the toplevel makefile includes 
makefiles from levels and then processes the resulting set of rules, 
rather than invoking itself recursively in subdirectories.

The reason I am in favor of gathering all rules in a single make 
execution is because I have been heavily influenced by a release 
engineer where I worked a couple of years ago, who would insist that 
makefiles be lists of "dependency/build instruction" rules, and a build 
should simply be collecting all the rules and trying to make the target 
binary.

He forced us to write component/subcomponent makefiles that would be 
included in a general makkefile that would basically collect them and 
make whatever target was specified, applying whatever rules were needed. 
Pseudo-targets were scarce and carefully thought out. Rules without 
dependencies were forbidden.

The gain was that makefiles were easy to understand since all rules were 
homogeneous, and that you were sure that whatever your last build was, 
doing a make of anything (a single .o, a library, the whole binary, a 
tar.gz for a release package) would only rebuild what was needed.

2) terse vs verbose.

I like terse more, and yes, I concur with Wolfgang that as far as output 
verbosity is concerned, this should be done natively in make, not in 
makefiles -- but it might be easier said than done, because the 'terse' 
output may not be easily deduced from the build command in the make rule 
that causes it.

So these would be Make patches, if any.

Amicalement,
-- 
Albert.