James Carlson <james.d.carlson at sun.com> writes:
> Roland Mainz writes:
> > Bill Sommerfeld wrote:
> > > On Tue, 2009-02-03 at 16:32 -0800, Mike Kupfer wrote:
> > > > Rainer suggested that it would be good for "make clobber" to get the
> > > > tree as close to a pristine condition as possible, which argues for
> > > > deleting directories. So, for example, his patch introduces a
> > > > CLOBBERDIRS variable to go along with CLOBBERFILES.
> > >
> > > Does this proposed change use rmdir or rm -rf to delete elements of
> > > CLOBBERDIRS?
> >
> > AFAIK it would be nice to get both CLOBBERDIRS which runs after
> > CLOBBERFILES and a CLEANDIRS variable which runs after CLEANFILES, both
> > implemented via @rmdir $(xxxDIRS) to get warnings when non-empty
> > directories remain.
This sounds reasonable if only for symmetries' sake, but in practice the
distinction doesn't make sense IMO. For files we distinguish between clean
and clobber insofar as clean only removes intermediate files (like object
files), while clobber also removes the final targets. I don't think we can
make that distinction for directories (those not being targets at all and
in almost all cases containing the final targets), so for simpicity I'd
like to keep it at CLOBBERDIRS only.
> I agree. I think it'd be a little strange to need rm -rf. I would
> think that you have ".make.state" floobydust only in directories that
> actually contain Makefiles, and those aren't ones you should be trying
> to clobber. (At least in the normal ON build process, where Makefiles
> are always versioned and not generated.)
As I wrote, I need the rm -rf only in the single case of ptools, which are
strange in this regard and it took me some time to figure out what was
going on there. As you can seen in $SRC/cmd/ptools/Makefile and
Makefile.ptool, in every subdir we create $(MACH) and optionally $(MACH64)
subdirs, change into those and run make -f ../../makefil...@. This is why
we have directories containing .make.state files, but no corresponding
Makefile.
Unfortunately, I couldn't figure out a clean way to avoid the rm -rf here.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
