RFR: 8329704: Implement framework for proper handling of JDK_LIBS

Magnus Ihse Bursie ihse at openjdk.org
Fri Apr 5 14:05:31 UTC 2024


On Fri, 5 Apr 2024 09:56:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the pinnacle of the recent stream of refactorings in the build system. This patch introduces a more abstract concept of "JDK_LIBS", where only the library name (e.g. "java" or "java.desktop:jawt") is specified, and the build system turns this into suitable linker flags: `-ljawt -L<correct path>` or `jawt.lib -libpath:<correct path>`, depending on linker. It will also automatically create proper dependencies.

The syntax for specifying JDK libraries can of course be discussed. I tried to align it with the current syntax for specifying source code, but it does not match 100%. The differences are:
* For source code, the default module is the current module, since the most common use is to include additional source directories from the current module. For libs, the default module is "java.base", since the by far most commonly included libs are `libjvm` and `libjava`.
* For source code, the full name of the directory is needed, so to include the `libjava` directory the name `libjava` needs to be specified. For libraries, the "lib-" prefix is dropped, and just the base name of the library is used, e.g. `java`.

This started out as a gradual extension of the use of e.g. `-ljava`, but after working with this patch for quite some time, I am not convinced it is ideal. If we were to align the syntax of libraries completely with source code, then the code will typically look like this:

    JDK_LIBS := libawt java.base:libjvm java.base:libjava, \

instead of (as currently in the patch):    

    JDK_LIBS := @:awt jvm java, \


It is longer, for sure, but maybe that does not matter as much. And it is definitely clearer.

Comments are welcome!

make/common/JdkNativeCompilation.gmk line 110:

> 108: # $1: The name of the rule (namespace)
> 109: # $2: The safe namespace of the library
> 110: define ResolveLibPath

This macro is a horrible mess. But, sort of the point of this PR was to collect all this horrible mess in a single place, instead of having this strewn out all over the code base. 

My intention is to make the placement of libraries during build more systematic in a future PR, so this function can be simplified.

make/common/JdkNativeCompilation.gmk line 195:

> 193:      $1_$2_STATIC_LIBRARY := true
> 194:   endif
> 195:   # Ideally, we should not hardcode these

This is also something I plan to address in an upcoming PR. (The poor handling of static libraries is basically what has driven this current round of refactorings.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18649#issuecomment-2039414005
PR Review Comment: https://git.openjdk.org/jdk/pull/18649#discussion_r1553336636
PR Review Comment: https://git.openjdk.org/jdk/pull/18649#discussion_r1553337734


More information about the build-dev mailing list