James Carlson writes:
> Rainer Orth writes:
> > James Carlson <james.d.carlson at sun.com> writes:
> > > 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.
>
> Maybe add $(MACH)/.make.* and $(MACH64)/.make.* to CLEANFILES?
I think I tried that, but maybe only in the subdirs themselves (which
doesn't work since running make clean there would recreate .make.state as a
side effect ;-)
> It's good that it's an unusual case. Maybe the simplest way out is to
> make those cases be the same as the others in the system -- put
> Makefiles in those $(MACH) and $(MACH64) directories, and build
> normally.
Fully agreed: the current structure is somewhat hard to understand if things
go wrong.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
