What to pass to --with-custom-make-dir? (original) (raw)

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 $(CUSTOMMAKEDIR)/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 $(CUSTOMMAKEDIR)/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 $(CUSTOMMAKEDIR)/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 CUSTOMMAKEDIR=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 CUSTOMMAKEDIR to be just “closed” but that doesn’t work for top-level:_ _$ make jdk CUSTOMMAKEDIR=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