[U-Boot] [PATCH] punt unused clean/distclean targets

[Graeme Russ <graeme.russ@gmail.com>]

On 18/09/11 18:22, Mike Frysinger wrote:
> On Sunday, September 18, 2011 03:26:38 Wolfgang Denk wrote:
>> Mike Frysinger wrote:
>>> The top level Makefile does not do any recursion into subdirs when
>>> cleaning, so these clean/distclean targets in random arch/board dirs
>>> never get used.  Punt them all.
>>
>> I think this is the wrong approach.  Would it not be better to get rid
>> of the 60 lines of clean/clobber target in the top level Makefile,
>> including it's brute force methods of "find ... | xargs rm -f" and
>> actually remove the files from the Makefiles in the respective
>> directories instead?
>>
>> This would for example allow that a board maintainer can fix the clean
>> / clobber rules for his code without having to edit the top level
>> Makefile.
> 
> yes & no.  i think we should have 1 clean/distclean target, but also have a 
> way for board maintainers to inject their own custom clean files.  preferably 
> via a .mk file in their board subdir.  this is moving in the direction of non-
> recursive make like the kernel does -- the top level would source all the 
> subfiles to figure out the master clean list.
> 
> however, the current build system has one advantage which i think we should 
> retain in the short term: `make distclean` always cleans out the targets 
> regardless of the current config.  for example, if you do `make bf537-stamp` 
> followed by `make harmony` followed by `make distclean`, Blackfin-specific 
> objects will still get cleaned out.

Can we not have make distclean/mrproper traverse ALL arch/SoC/board
directories and call their distclean/mrproper? Or have distclean/mrproper
read the .mk file for all arch/SoC/board directories?

Sure, it would be a little slower, but IMHO one would expect a speed
penalty from distclean/mrproper

I think that over the course of the next few releases, we will see more and
more granulation of the code - more distinct boundaries put in place around
'arches', 'SoCs', 'boards', etc - making each less dependent on each other.
My nirvana is for the ability to create an entirely new
arch/SoC/board/driver/lib/whatever and have bare minimal (ideally zero)
impact on anyone else.

I mean, it irks me to no end that /common/serial.c, /drivers/serial.c and
/include/serial.h are such an ugly mess of #ifdef's - I'm working on a new
SoC at the moment, and it just plain weird that I have to touch these :(

Regards,

Graeme