[Top][All Lists]

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

Re: exception to Paul's Second Rule?

From: Noel Yap
Subject: Re: exception to Paul's Second Rule?
Date: Thu, 16 Oct 2003 18:21:22 -0400

Robert Mecklenburg wrote:
> > From: "Noel Yap" <address@hidden>
> > Robert Mecklenburg wrote:
> > > %.o: %.c %.mkdir
> > >
> > > So I was thinking the target would be, say, "out/bar.o".  Now, with the
> > > "slow" version it has prereq of "out/bar.mkdir" (In the slow version we
> omit
> > > the .. path component.)  Then the command script executes:
> > >
> > >     @mkdir -p $(dir out/bar.mkdir)
> > >     @touch out/bar.mkdir
> >
> > I see.  Doing this would create one directory per object file
> I must be off today, I don't understand.  This would execute mkdir for each
> object file, but it would not create a new directory each time (or did I
> miss something?):
>     @mkdir -p $(dir out/bar.mkdir)
> =>
>     @mkdir -p out

No, I'm the one that's off.  I think the only differences are 
's|\.\./\.\.\.|\.mkdir|' and there'd be one .mkdir file per .o file.  Did I get 
it right this time?

> If many .o files live in out, then you would still get only one directory.
> You _would_ get many zero-length timestamp files out/bar.mkdir,
> out/foo.mkdir, etc.

Yup, I guess I did :-)

> > and would still have a race condition when using --jobs.
> Again, I'm not sure I understand you.  Directory creation on unix is atomic.
> There can be no race conditions with mkdir.  There can be with the execution
> of the touch, but that is non-critical and there would be no ill effects of
> having a second touch "beat" the first touch.
> What did I miss?

I think "mkdir -p" may not be atomic, but I could be wrong.

Hmmm, at first I thought that gmake should prevent the race condition due to 
the dependency on %/../... since that should stat to the same file (but not if 
the dependency is on %.mkdir), but now I'm thinking there may still be room for 
a race condition. 
If there is, I think you're right in that there's really no harm done.

NOTICE: If received in error, please destroy and notify sender.  Sender does 
not waive confidentiality or privilege, and use is prohibited.

reply via email to

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