From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sun, 18 Sep 2011 23:08:35 +1000 Subject: [U-Boot] [PATCH] punt unused clean/distclean targets In-Reply-To: <201109180422.09040.vapier@gentoo.org> References: <1316323020-4027-1-git-send-email-vapier@gentoo.org> <20110918072638.B80471407963@gemini.denx.de> <201109180422.09040.vapier@gentoo.org> Message-ID: <4E75ED53.9020006@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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