[U-Boot] Nested Makefiles

[U-Boot] Nested Makefiles

[Simon Glass]

Hi,

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?

So for example:

$ make all
CC   drivers/spi/tegra2_spi.c
Warning: blah blah blah
CC   board/fred/board.c
CC   arch/arm/lib/board.c
LD   u-boot
$

Unfortunately I don't even know the name for this feature so wasn't
able to find a reference to it in the mailing list archives.

Regards,
Simon

[U-Boot] Nested Makefiles

[Wolfgang Denk]

Dear Simon Glass,

In message <BANLkTinE=tPVZfdBDJe5m79wedznFYv5FQ@mail.gmail.com> you 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.

But please note that I think that the Linux implementation sucks, and
ditto for all other projects that copied this method.

I think it is fundamentally wrong to implement such a feature (let's
call it "terse make output") in the Makefiles of many projects, using
a lot of trickery and magic.  If a specific verbosity of make output
is needed, this should most naturally be implemented as a feature in
make itself - we already have make options like "-d" (for very verbose
output) or "-s" (for silent mode), so why not add a new verbosity
level which produces exactly the short output format you want?


So yes, patches are welcome, but these should go directly to the make
mailing lists / patch system, see
http://savannah.gnu.org/mail/?group=make

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anything that is worth doing at all is worth doing well.
                                       -- Philip Earl of Chesterfield

[U-Boot] Nested Makefiles

[Måns Rullgård]

Wolfgang Denk <wd@denx.de> writes:

> Dear Simon Glass,
>
> In message <BANLkTinE=tPVZfdBDJe5m79wedznFYv5FQ@mail.gmail.com> you 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.
>
> But please note that I think that the Linux implementation sucks, and
> ditto for all other projects that copied this method.
>
> I think it is fundamentally wrong to implement such a feature (let's
> call it "terse make output") in the Makefiles of many projects, using
> a lot of trickery and magic.

Aside from the pros and cons of the terse output, getting rid of the
recursive makefiles should speed up the u-boot build dramatically.  In a
typical build, it spends a huge amount of time going in and out of
directories only to determine there was nothing to do.

No, I'm not volunteering to rewrite the makefiles.

-- 
M?ns Rullg?rd
mans at mansr.com

[U-Boot] Nested Makefiles

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110616/7f705aa7/attachment.pgp 

[U-Boot] Nested Makefiles

[Mike Frysinger]

On Thursday, June 16, 2011 19:03:21 M?ns Rullg?rd wrote:
> Aside from the pros and cons of the terse output, getting rid of the
> recursive makefiles should speed up the u-boot build dramatically.  In a
> typical build, it spends a huge amount of time going in and out of
> directories only to determine there was nothing to do.

indeed.  it shouldnt be that bad now that more stuff has converted to 
FOO-$(CONFIG) syntax.  it could probably even be done piece by piece rather 
than the whole tree to make transition easier.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110616/f9346184/attachment.pgp 

[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.

[U-Boot] Nested Makefiles

[Rod Boyce]

On 18/06/11 14:49, Albert ARIBAUD wrote:
> 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,
All,

My comments on this are that non-recursive makefiles are much eaiser to 
understand.  There are 2 articles on the internet have have strongly 
influenced how I write makefiles.  The first is titled 'Recursive make 
considered harmful' and the second is about dependencies titled 
'Advanced auto-dependency generation'.  I am happy to send out links in 
a follow up e-mail if asked but I don't want to open old wounds on these 
here.  I agree with what Amicalement has said so far.  As an example 
from my own experience I have taken a recursive build system that took 
40-minutes to output a build and reduced this down to 4-minutes with 
about 3-times the flexibility.  Adding a new target was as simple as 
adding a line in a makefile and creating a new header file.

While I think the u-boot build system is quite flexible for what it does 
and very fast I would be happy to help out on this endeavor.

On the terse vs verbose debate make already has a feature that does this 
albeit there is no output from make in standard out when the silent (-s) 
option is enabled.

A fragment from my common makefile system is this:
# New improved verbose mode
V ?= 0
ifeq ($(V),1)
NOOUT := > /dev/null
else
MAKEFLAGS += -s
endif

This means that I switch on silent make mode unless the developer add 
V=1 to the make command line and I add to the each rule a line similar to:
@echo "Compiling : $(notdir $<)" $(NOOUT)
or
@echo "Link  app : $@" $(NOOUT)

This produces an output vaguely similar to the Linux kernel or busybox 
output but without all the extra macros.

I have written a non-recursive makefile build system that I have 
licensed under BSD.  It currently supports GCC cortex-M3, SDCC, gcc host 
for tools.  I have build the system such that it is very easy to add 
compilers, architectures, different hosts (although Linux is only 
supported@the moment).
I would be happy to donate it to u-boot if others were interested in 
adding to it as well.  I am currently the only user and developer of it  
so changing the license will not be a problem if required.
If there is interest I would be happy to put it up on one of the git 
hosting website of others to review.

Regards,
Rod Boyce

[U-Boot] Nested Makefiles

[Mike Frysinger]

On Saturday, June 18, 2011 09:49:36 Albert ARIBAUD wrote:
> 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".
> 
> There are two independent issues/topics here, and IIUC, one would
> require patches to U-Boot and the other, patches to make :

i know there are, but i was asking for clarification on Wolfgang's statement 
from Wolfgang
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110618/53ea247b/attachment.pgp 

[U-Boot] Nested Makefiles

[Wolfgang Denk]

Dear Rod Boyce,

In message <4DFCC7BC.7070509@teamboyce.co.uk> you wrote:
>
> here.  I agree with what Amicalement has said so far.  As an example

You mean Albert.  "Amicalement" is French and means "best regards" ;-)

> A fragment from my common makefile system is this:
> # New improved verbose mode
> V ?= 0
> ifeq ($(V),1)
> NOOUT := > /dev/null
> else
> MAKEFLAGS += -s
> endif

I think it is a bit of overkill to introduce code just to set a plain
simple command option.

Instead of inventing new magic that needs to be documented we should
rather just use the standard make options directly, I stronly
prefer to use

	make -s

if no output is wanted (or rather run "./MAKEALL name" which already
does exactly that, and more).


> This means that I switch on silent make mode unless the developer add

I am not a friend of changinmg the default behaviour of standard
tools.  If someone wants silent operation, he should use the silent
flag.

> V=1 to the make command line and I add to the each rule a line similar to:
> @echo "Compiling : $(notdir $<)" $(NOOUT)
> or
> @echo "Link  app : $@" $(NOOUT)

It will not stay as simple - the whole trickery in the Linux makefiles
is there for some good reasons.  And don't think I want to have this
here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1

[U-Boot] Nested Makefiles

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201106181342.06716.vapier@gentoo.org> you wrote:
>
> > >> 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".
> > 
> > There are two independent issues/topics here, and IIUC, one would
> > require patches to U-Boot and the other, patches to make :
> 
> i know there are, but i was asking for clarification on Wolfgang's statement
> from Wolfgang

You did not really ask a question, you just posted a comment.

But yes, you are right.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The ideal situation is to have massive computing power right at home.
Something that dims the streetlights and shrinks the picture  on  the
neighbours' TVs when you boot it up.

[U-Boot] Nested Makefiles

[Scott Wood]

On Sat, 18 Jun 2011 15:49:36 +0200
Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:

> 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.

Couldn't it simply print the name of the target buing built?

-Scott

[U-Boot] Nested Makefiles

[Mike Frysinger]

On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk <wd@denx.de> wrote:
> I think it is fundamentally wrong to implement such a feature (let's
> call it "terse make output") in the Makefiles of many projects, using
> a lot of trickery and magic. ?If a specific verbosity of make output
> is needed, this should most naturally be implemented as a feature in
> make itself - we already have make options like "-d" (for very verbose
> output) or "-s" (for silent mode), so why not add a new verbosity
> level which produces exactly the short output format you want?
>
>
> So yes, patches are welcome, but these should go directly to the make
> mailing lists / patch system, see
> http://savannah.gnu.org/mail/?group=make

not to kick sand just for fun, but this is an example of you getting
final veto power.  this has been requested by many people, and ive
seen very few people against it (off the top of my head, i can only
recall you, but i havent looked at previous threads to be sure).

i'm not saying your logic is without merit, just that in all
practicality, i dont think it's going to happen the way you desire.
-mike

[U-Boot] Nested Makefiles

[Simon Glass]

On Mon, Jun 20, 2011 at 12:53 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk <wd@denx.de> wrote:
>> I think it is fundamentally wrong to implement such a feature (let's
>> call it "terse make output") in the Makefiles of many projects, using
>> a lot of trickery and magic. ?If a specific verbosity of make output
>> is needed, this should most naturally be implemented as a feature in
>> make itself - we already have make options like "-d" (for very verbose
>> output) or "-s" (for silent mode), so why not add a new verbosity
>> level which produces exactly the short output format you want?
>>
>>
>> So yes, patches are welcome, but these should go directly to the make
>> mailing lists / patch system, see
>> http://savannah.gnu.org/mail/?group=make
>
> not to kick sand just for fun, but this is an example of you getting
> final veto power. ?this has been requested by many people, and ive
> seen very few people against it (off the top of my head, i can only
> recall you, but i havent looked at previous threads to be sure).
>
> i'm not saying your logic is without merit, just that in all
> practicality, i dont think it's going to happen the way you desire.
> -mike
>

Hi,

Great to see the discussion here. My feeling is that the right
approach is for the subdir Makefiles to be #included so that make can
operate the way it was originally intended (full tree dependency). We
don't have the kind of memory limitations that once made the size of
its dependency table worth worrying about.

The verbosity or not of make is mostly a side issue in my view since
it is possible to have this approach and still print all the gcc
commands lines. I don't personally find it useful 90% of the time, but
that's personal preference. The one message that I think is
superfluous is 'Entering directory... / Leaving directory ...'.
Perhaps there is disagreement on this too? I think it is better to
include the full path with each filename that is built. My IDE agrees
:-)

The change I am talking about does not affect make at all, and I can't
think what manner of patches might get make to automatically build a
picture from all subdirectories before starting its work. If I were
the make maintainer I would almost certainly reject them.

I would like to name this feature 'Full dependency make' instead of
'terse make output'. The terse-ness could be an option.

Who was it that volunteered to modify the makefiles? :-) I was very
encouraged by Mike's comment earlier:

> indeed.  it shouldnt be that bad now that more stuff has converted to
> FOO-$(CONFIG) syntax.  it could probably even be done piece by piece rather
> than the whole tree to make transition easier.

Indeed it is not like the U-Boot subdir Makefiles are a mess - they
are pretty tidy and describe the dependencies in a clean way that
should be usable when included by a top-level Makefile.

Regards,
Simon

[U-Boot] Nested Makefiles

[Wolfgang Denk]

Dear Simon Glass,

In message <BANLkTi=SJseedJ=vcWr2i+kAsc8A_4EqATf69+y5SKoQH2fomg@mail.gmail.com> you wrote:
>
> >> So yes, patches are welcome, but these should go directly to the make
> >> mailing lists / patch system, see
> >> http://savannah.gnu.org/mail/?group=make
> >
> > not to kick sand just for fun, but this is an example of you getting
> > final veto power. ?this has been requested by many people, and ive
> > seen very few people against it (off the top of my head, i can only
> > recall you, but i havent looked at previous threads to be sure).
> >
> > i'm not saying your logic is without merit, just that in all
> > practicality, i dont think it's going to happen the way you desire.
> 
> Great to see the discussion here. My feeling is that the right
> approach is for the subdir Makefiles to be #included so that make can
> operate the way it was originally intended (full tree dependency). We
> don't have the kind of memory limitations that once made the size of
> its dependency table worth worrying about.

Be casreful not to mix topics.  Mike's message to which you reply here
has actually asolutely nothing to do with nested or recursive
Makefiles or such.  He is referring to the other topic (terse make
output) instead.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What's the sound a name makes when it's dropped?

[U-Boot] Nested Makefiles

[Wolfgang Denk]

Dear Mike Frysinger,

In message <BANLkTim5nXA8fF=O24gHEGL+XyBTQLMJUA@mail.gmail.com> you wrote:
> On Thu, Jun 16, 2011 at 18:03, Wolfgang Denk <wd@denx.de> wrote:
> > I think it is fundamentally wrong to implement such a feature (let's
> > call it "terse make output") in the Makefiles of many projects, using
> > a lot of trickery and magic. =A0If a specific verbosity of make output
> > is needed, this should most naturally be implemented as a feature in
> > make itself - we already have make options like "-d" (for very verbose
> > output) or "-s" (for silent mode), so why not add a new verbosity
> > level which produces exactly the short output format you want?
> >
> >
> > So yes, patches are welcome, but these should go directly to the make
> > mailing lists / patch system, see
> > http://savannah.gnu.org/mail/?group=3Dmake
> 
> not to kick sand just for fun, but this is an example of you getting
> final veto power.  this has been requested by many people, and ive
> seen very few people against it (off the top of my head, i can only
> recall you, but i havent looked at previous threads to be sure).
> 
> i'm not saying your logic is without merit, just that in all
> practicality, i dont think it's going to happen the way you desire.

We should probably split this thread and adapt the Subject, as we are
discussing two completely independend topics here:

One is about "Nested Makefiles" (or recursive Makefiles), which the
subject mentions.  I have to admit that I don't have a clear opinion
about this yet, so I lean back and wait what the results of this
discussion might be.  When we see any code we have probably a better
base to discuss this.

The other topic is actually terse make output, and here indeed I
insist that the problem should be solved at the base, like I always
insisted that GCC / libgcc issues should not be worked around again
and again and in every software package that uses GCC but rather at
the base of the problem, in GCC itself.

Any other approach might just appear to need less efforts, but you
have to multiply this with the number of projects that do the same,
and the silly waste of efforts for multiple similar implementations.
In total, a clean solution at the correct place is not only less
effort, but the only mentally clean solution.

At least that's my 0.02 <insert your favorite unit of currency here>.

YMMV...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_

[U-Boot] Nested Makefiles

[Simon Glass]

On Mon, Jun 20, 2011 at 3:17 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <BANLkTi=SJseedJ=vcWr2i+kAsc8A_4EqATf69+y5SKoQH2fomg@mail.gmail.com> you wrote:
>>
>> >> So yes, patches are welcome, but these should go directly to the make
>> >> mailing lists / patch system, see
>> >> http://savannah.gnu.org/mail/?group=make
>> >
>> > not to kick sand just for fun, but this is an example of you getting
>> > final veto power. ?this has been requested by many people, and ive
>> > seen very few people against it (off the top of my head, i can only
>> > recall you, but i havent looked at previous threads to be sure).
>> >
>> > i'm not saying your logic is without merit, just that in all
>> > practicality, i dont think it's going to happen the way you desire.
>>
>> Great to see the discussion here. My feeling is that the right
>> approach is for the subdir Makefiles to be #included so that make can
>> operate the way it was originally intended (full tree dependency). We
>> don't have the kind of memory limitations that once made the size of
>> its dependency table worth worrying about.
>
> Be casreful not to mix topics. ?Mike's message to which you reply here
> has actually asolutely nothing to do with nested or recursive
> Makefiles or such. ?He is referring to the other topic (terse make
> output) instead.

Hi Wolfgang,

OK sorry. It was the nested/recursive makefiles with which I started
this thread. I think it might have been misunderstood as a question
about terse make but it wasn't.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> What's the sound a name makes when it's dropped?
>

[U-Boot] Nested Makefiles

[Mike Frysinger]

On Monday, June 20, 2011 16:30:15 Simon Glass wrote:
> On Mon, Jun 20, 2011 at 12:53 PM, Mike Frysinger wrote:
> > indeed.  it shouldnt be that bad now that more stuff has converted to
> > FOO-$(CONFIG) syntax.  it could probably even be done piece by piece
> > rather than the whole tree to make transition easier.
> 
> Indeed it is not like the U-Boot subdir Makefiles are a mess - they
> are pretty tidy and describe the dependencies in a clean way that
> should be usable when included by a top-level Makefile.

at one point i wrote a generic board/board.mk that board/*/Makefile could 
inherit.  then all board/*/Makefile would need is to declare COBJS-y.  i'm not 
sure if that's a useful step, or if we just pick a single dir like common and 
make it work by a direct include of the top level Makefile.  once we get those 
issues hashed out, we can move on to others one by one.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110620/756ae62b/attachment.pgp