All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] punt unused clean/distclean targets
Date: Mon, 19 Sep 2011 07:10:57 +0200	[thread overview]
Message-ID: <201109190710.57876.marek.vasut@gmail.com> (raw)
In-Reply-To: <201109190059.55664.vapier@gentoo.org>

On Monday, September 19, 2011 06:59:52 AM Mike Frysinger wrote:
> On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote:
> > 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?
> 
> if it wasn't clear in my last e-mail, i want to move in the direction of
> .mk files that the top level would include them and thus all the specific
> cruft would be kept there
> 
> after all, the list of things to clean should be obvious once we have more
> kbuild style system: if it's listed as a file to build, then it should get
> cleaned.

And who's porting the kbuild style system to uboot, is there something like that 
going on already ?

Cheers
> -mike

  reply	other threads:[~2011-09-19  5:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-18  5:17 [U-Boot] [PATCH] punt unused clean/distclean targets Mike Frysinger
2011-09-18  7:26 ` Wolfgang Denk
2011-09-18  8:22   ` Mike Frysinger
2011-09-18 13:08     ` Graeme Russ
2011-09-19  4:59       ` Mike Frysinger
2011-09-19  5:10         ` Marek Vasut [this message]
2011-09-19  5:30           ` Mike Frysinger
2011-09-19  6:57             ` Wolfgang Denk
2011-09-19  5:11         ` Graeme Russ
2011-09-19  5:32           ` Mike Frysinger
2011-09-19  6:54         ` Wolfgang Denk
2011-09-19 14:28           ` Mike Frysinger
2011-09-19 18:29           ` Scott Wood
2011-09-19 20:57       ` [U-Boot] serial ifdef mess Mike Frysinger
2011-09-20  0:41         ` Graeme Russ
2011-09-20  0:52           ` Mike Frysinger
2011-09-20  1:07             ` Graeme Russ
2011-09-20  4:28               ` Simon Glass
2011-09-20  4:44                 ` Mike Frysinger
2011-09-20  5:12                 ` Graeme Russ
2011-09-20  7:29                 ` Wolfgang Denk
2011-09-20  4:40               ` Mike Frysinger
2011-10-13 16:54 ` [U-Boot] [PATCH v2] punt unused clean/distclean targets Mike Frysinger
2011-10-15 20:20   ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201109190710.57876.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.