On Fri, 5 Apr 2024 09:56:48 GMT, Magnus Ihse Bursie <i...@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
