RFR: 8026144: Missing mkdir in Images.gmk
Volker Simonis
volker.simonis at gmail.com
Thu Oct 10 08:45:24 UTC 2013
On Thu, Oct 10, 2013 at 10:08 AM, Erik Joelsson <erik.joelsson at 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
More information about the build-dev
mailing list