On Wed, 2016-06-29 at 20:34 -0400, LMH wrote: > If you don't mind my asking, how does the above "archdir" solution > compare with what you suggested as far as defining $(BDIR) as a > prerequisite for $(BDIR)/SMD2_i386.exe? > Is there any difference?
It's not good enough to list archdir as a prerequisite of the "all" target, if you want to use parallel builds and make it reliable. Make is free to build any targets which don't have a prerequisite relationship with each other simultaneously. So for: all: $(archdir) $(BDIR)/SMD2_i386.exe make can invoke the recipes of both the archdir and the SMD2_i386.exe targets at the same time. Depending on which order the OS decided to run them in or other factors, it's possible (although probably unlikely), that the latter would try to use the archdir directory before the former created it. If you want to use real targets to create the directories, then you must ensure that every target that expects to have the directory already created, must list that directory target as a prerequisite. > Your shell solution is simpler than mine in that it doesn't need to > actually check if the directory exists and just suppresses the error > message if it does. I am wondering if there is any value to actually > making the check, but I can't think of any off hand. Not only is there no value in it, it's actually LESS robust to make the check because between the time make checks for the directory and the time it runs "mkdir", some other program could have created it. Since you don't really care whether the directory existed before or not, you just want to be sure it exists afterwards, you should use "mkdir -p" (that's why it was created). The downside of using a shell function as I did is that, since it's run whenever make parses the makefile not when rules are invoked, the directory will be created every time make is invoked, even if no target actually needs to put a file in that directory. The upside is you don't need to list the directory is a prerequisite of every target since it's always created, so the implementation is simpler. So it's up to you. _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make