[U-Boot] Nested Makefiles

Albert ARIBAUD
2011-06-18T13:49:36Z

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.