On Thu, Oct 10, 2013 at 10:08 AM, Erik Joelsson <erik.joels...@oracle.com>wrote:
> > On 2013-10-10 03:02, David Holmes wrote: > >> On 9/10/2013 11:30 PM, Erik Joelsson wrote: >> >>> I just hit this race when building in jprt. Adding the standard mkdir -p >>> lines should fix it. >>> >>> https://bugs.openjdk.java.net/**browse/JDK-8026144<https://bugs.openjdk.java.net/browse/JDK-8026144> >>> >>> http://cr.openjdk.java.net/~**erikj/8026144/webrev.jdk.01/<http://cr.openjdk.java.net/~erikj/8026144/webrev.jdk.01/> >>> >> >> Hmmm. Isn't the real problem that there is a missing dependency on the >> prior unzipping target (that already does the mkdir). To be pedantic I >> suppose all three targets should have a dependency on a "prepare" target >> that does the mkdir. >> >> Adding mkdir to all of them does avoid the problem though. >> >> Of those options, I would say a separate rule for the directory would be > more correct. There is no need to depend on the actual unzipping. It would > also be complicated by the unzipping rule being a pattern rule, making it > trickier to follow the dependency chain when reading the code. > > It's a matter of design choice I suppose. It's slightly more efficient to > declare a rule for the directory alone that does the mkdir. At least on > cygwin where execs are expensive. There are instances of this design in the > build, but in most places we use the $(install-file) or similar macros in > the recipe that does mkdir -p, just because it's simpler, especially for > generated rules. In this case I opted for the smaller change and more > common pattern. > > /Erik > I just want to add that parallel "mkdir -p <path>" commands can fail on AIX if <path> is on an NFS share. While knowing that AIX is not one of the main OpenJDK platforms I would nevertheless prefer the conceptually cleaner way of having a separate rule for the path to prevent parallel mkdirs for the same directory. Regards, Volker
