%% Noel Yap <[EMAIL PROTECTED]> writes:
>> $(shell for d in $(dirs); do [ -d $$d ] || mkdir -p $$d; done)
ny> Exactly. IMHO, it also unnecessarily spawns off a bunch of
ny> processes. Using the hack (or, if widely accepted, idiom :-), a
ny> shell for mkdir is spawned only if the directory hasn't been
ny> created. Initially, this may spawn more processes than the
ny> $(shell) alternative, but it'll spawn none thenceforth.
The alternative above spawns exactly one shell every time you run make,
regardless of how many directories you need. To me that's not a big
deal, but I guess YMMV :).
ny> %: %/../...
ny> @: >> $@
ny> .PRECIOUS: %/../...
ny> %/../...:
ny> @mkdir -p $(dir $*) && : >> $(dir $*)$(@F)
ny> $ gmake --jobs=2 aoeu/aoeu/aoeu aoeu/ueoa/ueoa
ny> it looks like there's an opportunity for a race condition. Is
ny> this right?
Yes, but as Robert said I don't think it's an issue. The actual
mkdir(2) system call is atomic, I'm pretty sure. Yes, if you do
multiple system calls to create subdirectories then there could be
interference but the result is the same.
The only possible problem you might have is if you run two mkdirs at the
same time and one of them _fails_ and exits with a non-0 exit code, then
your rule above would fail and the build would fail.
ny> I haven't heard anyone say this violates Paul's Secord Rule.
Hm. Well, I think it follows the spirit of it. The idea behind that
rule is to keep people from trying to do silly things like:
foo.o: foo.c
$(CC) $(CFLAGS) -o objdir/foo.o -c foo.c
or whatever. Your rule does the same thing _in effect_.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Help-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-make
