[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.
Noel
--
NOTICE: If received in error, please destroy and notify sender. Sender does
not waive confidentiality or privilege, and use is prohibited.
- Re: wildcard recursive?!, (continued)
- Re: wildcard recursive?!, Dan Kegel, 2003/10/17
- RE: wildcard recursive?!, Sylvain Becker, 2003/10/17
- RE: wildcard recursive?!, Paul D. Smith, 2003/10/17
- RE: wildcard recursive?!, Sylvain Becker, 2003/10/17
- RE: wildcard recursive?!, Paul D. Smith, 2003/10/17
- Re: wildcard recursive?!, Noel Yap, 2003/10/17
Re: exception to Paul's Second Rule?, Noel Yap, 2003/10/16
Re: exception to Paul's Second Rule?, Benoit Poulot-Cazajous, 2003/10/24