[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to create a single rule to build a directory as necessary

From: Paul Smith
Subject: Re: how to create a single rule to build a directory as necessary
Date: Tue, 22 Sep 2009 15:43:43 -0400

On Tue, 2009-09-22 at 13:19 -0400, Sam Steingold wrote:
> Thanks for the informative reply!
> Paul Smith wrote:
> > On Tue, 2009-09-22 at 11:44 -0400, Sam Steingold wrote:
> >> I, too, am struggling with rebuilding a directory.
> >> it appears that the rule:
> >>
> >> gllib: config.status
> >>    mkdir -p gllib; cd gllib; make
> >>
> >> is wrong because the script "mkdir ..." is always executed, regardless of 
> >> whether config.status has changed or not.
> >> So, what is the right way to handle this?
> > 
> > The short answer is that using a directory as a target in make is almost
> > never correct, unless it's a .PHONY target or the equivalent.
> so what is this SUBDIRS automake thingie?
> how does it work?

Well, automake generates standard makefiles so you can go check it out,
but as far as I'm aware it does just what I mentioned (when generating
recursive makefiles): it ALWAYS goes into EVERY directory and runs make
there.  It's up to that sub-make to determine if the directory is really
up to date or not; there's no way that can be known by the upper-level
makefile, unless that makefile had knowledge of all the dependency
relationships... and if it already has that then why bother to invoke
the sub-make in the first place?  The upper-level make could just do it

> > The problem is that the modification time on a directory means something
> > that is not really appropriate for make: the modification time on a
> > directory changes whenever the DIRECTORY ITSELF changes.  When does a
> > directory change?  It changes whenever any element in the directory is
> > renamed or deleted, or a new element is created in the directory.  In
> > short, if you run "ls -a" before and after some command and the output
> > is identical, then the directory was not modified.
> this makes perfect sense.
> thanks.
> how about this addition then:
> gllib: config.status
>       mkdir -p gllib; cd gllib; make
>       touch gllib/.stamp; rm -f gllib/.stamp
> adding and removing the .stamp file will modify the directory, right?

Well, you can just "touch gllib" directly, rather than making/removing
files, but this still has lots of issues as Philip describes.

> > Your problem here is more conceptual than anything.  What, in words, are
> > you really trying to get make to do?  How does the upper level makefile
> > know, really, that it does or doesn't need to invoke the sub-make?  It
> > can't know that... unless it invokes the submake to see whether anything
> > needs to be done.
> I need a few files which are created in gllib by make.
> Do I need to explicitly type
> gllib/foo gllib/bar : config.status
>       mkdir -p gllib; cd gllib; make

You still have to consider prerequisites.  Is it true that the one and
only reason gllib/foo or gllib/bar might need to be rebuilt is because
of a change to config.status?

If so, then that will work.  But if they could change because of a
change to some other file (source in the gllib directory for example)
then this isn't sufficient.

> > In a standard recursive make environment, sub-makes are almost always
> > set up as .PHONY, so they're always invoked, to be sure that their
> > content is up to date.  That's why recursive makes are slower,
> > typically, than non-recursive makes.
> so, if I add gllib to .PHONY, the commands will be always executed, even with 
> the .stamp trick?

Yes; if you do this you should just not bother with the ".stamp
trick" (which, again, isn't a good trick anyway :-)).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]