What to pass to --with-custom-make-dir?

Christian Thalinger cthalinger at twitter.com
Tue Mar 7 17:36:23 UTC 2017


> On Mar 6, 2017, at 10:17 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> 
> 
> On 2017-03-07 03:22, David Holmes wrote:
>> On 7/03/2017 6:32 AM, Christian Thalinger wrote:
>>> 
>>>> On Mar 6, 2017, at 8:51 AM, Christian Thalinger <cthalinger at twitter.com> wrote:
>>>> 
>>>> 
>>>>> On Mar 3, 2017, at 4:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>> I think you need to pass an absolute directory, in which all the custom files, regardless of repo, are located. That is essentially how we use it - jdk/make/closed has files included from other repos. Of course that only works if names are unique.
>>>> 
>>>> Absolute directory to where?  Is $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk not under jdk/make/closed?
>>> 
>>> After reading your message a couple of times :-) I got it. Basically pass /repo/make/closed and have all files there.
>> 
>> It has to be an absolute directory somewhere, not relative to whatever the current make command is executing. So it could be /repo/jdk/make/closed if you wanted it to be.
>> 
>>> But why?  That doesn’t make any sense since there is a jdk/make/closed directory.
>> 
>> IIRC this was initially a mechanism for customizing jdk/make files, then another part of the forest also wanted a "closed" custom file and so it was "enhanced" to allow that. In 9 of course this is all handled completely differently now.
>> 
> Since we didn't have a top level closed repository in JDK8, we put all common closed makefiles (and autoconf) in jdk/make/closed. This is why the custom makefile includes all point to the same dir in 8u.

Ahh!  That explains the behavior in 8.  I thought there was a closed repository in top.  Thanks.

> 
> In JDK 9 we added a top level closed repository and created a macro to handle the includes so that any closed implementor may define that macro as they like and consequently, put their closed additions in any structure they like.

Yes, much better.

> 
> /Erik
>> David
>> 
>>>> 
>>>>> 
>>>>> David
>>>>> 
>>>>> On 4/03/2017 9:11 AM, Rob McKenna wrote:
>>>>>> Hi Christian,
>>>>>> 
>>>>>> I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more appropriate
>>>>>> venue for this discussion.
>>>>>> 
>>>>>>  -Rob
>>>>>> 
>>>>>> On 03/03/17 10:19, Christian Thalinger wrote:
>>>>>>> At Twitter we are using the custom extension mechanism to separate our additional code from upstream in order to minimize conflicts.  Yesterday I wanted to add a custom extension for:
>>>>>>> 
>>>>>>> jdk/make/lib/ServiceabilityLibraries.gmk
>>>>>>> 
>>>>>>> which has this include directive:
>>>>>>> 
>>>>>>> # Include custom extensions if available.
>>>>>>> -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk
>>>>>>> 
>>>>>>> We are already using the mechanism for top-level make files, e.g. make/Main.gmk:
>>>>>>> 
>>>>>>> # Include the corresponding custom file, if present.
>>>>>>> -include $(CUSTOM_MAKE_DIR)/Main.gmk
>>>>>>> 
>>>>>>> and we a configuring with:
>>>>>>> 
>>>>>>> --with-custom-make-dir=make/closed
>>>>>>> 
>>>>>>> This works fine for make/ but not for jdk/make/:
>>>>>>> 
>>>>>>> $ make jdk CUSTOM_MAKE_DIR=make/closed
>>>>>>>>>>>>>> 
>>>>>>> ## Starting jdk
>>>>>>> lib/ServiceabilityLibraries.gmk:27: make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory
>>>>>>> make[2]: *** No rule to make target `make/closed/lib/ServiceabilityLibraries.gmk'.  Stop.
>>>>>>> make[1]: *** [libs-only] Error 2
>>>>>>> make: *** [jdk-only] Error 2
>>>>>>> 
>>>>>>> (I changed "-include" to “include” to provoke the error.)
>>>>>>> 
>>>>>>> jdk/make/ files expect CUSTOM_MAKE_DIR to be just “closed” but that doesn’t work for top-level:
>>>>>>> 
>>>>>>> $ make jdk CUSTOM_MAKE_DIR=closed
>>>>>>> /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such file or directory
>>>>>>> make: *** No rule to make target `closed/Main.gmk'. Stop.
>>>>>>> 
>>>>>>> How is this supposed to work?




More information about the build-dev mailing list