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