Right now `CompileJavaModules.gmk` contains two different part: one part with
the functionality needed to compile a java module, and one part were all
special requirements for all modules are listed.
The second part should be removed from `CompileJavaModules.gmk`, and instead
listed directly
> Right now `CompileJavaModules.gmk` contains two different part: one part with
> the functionality needed to compile a java module, and one part were all
> special requirements for all modules are listed.
>
> The second part should be removed from `CompileJavaModules.gmk`, and instead
>
The hard-coded list of modules in `make/common/Modules.gmk` has always been a
wart in the build system. We pride ourself on using discovery instead of
hard-coded list. In this case, it is not possible to do do auto-discovery,
since the different module sets are configured, not determined.
Thus
> Right now `CompileJavaModules.gmk` contains two different part: one part with
> the functionality needed to compile a java module, and one part were all
> special requirements for all modules are listed.
>
> The second part should be removed from `CompileJavaModules.gmk`, and instead
>
On Tue, 15 Dec 2020 16:53:46 GMT, Alan Bateman wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
>>
In `Docs.gmk` there are some hard-coded links to online URL documentation and
bug reporting locations. These should not reside in the make file per se, but
instead move to the `make/conf` directory.
-
Commit messages:
- 8258420: Move URL configuration from Docs.gmk to conf dir
On Tue, 15 Dec 2020 18:15:28 GMT, Magnus Ihse Bursie wrote:
>> The hard-coded list of modules in `make/common/Modules.gmk` has always been
>> a wart in the build system. We pride ourself on using discovery instead of
>> hard-coded list. In this case, it is not possible to do do auto-discovery,
On Tue, 15 Dec 2020 16:11:45 GMT, Magnus Ihse Bursie wrote:
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
>
On Tue, 15 Dec 2020 20:27:36 GMT, Magnus Ihse Bursie wrote:
>> This looks better but I think we need to find better names for the conf
>> files. Prefixing them with "module-sets" looks really strange.
>> JRE_TOOL_MODULES in module-sets-classloaders.conf might also need to be
>> re-examined
On Tue, 15 Dec 2020 20:32:05 GMT, Magnus Ihse Bursie wrote:
>> I thought it was a consistent and clear naming scheme. :-) But I guess to
>> each their own...
>>
>> Would `classloader-modules.conf`, `docs-modules.conf` and
>> `build-modules.con` be better? Otherwise you'll need to come up with
On Tue, 15 Dec 2020 19:28:33 GMT, Alan Bateman wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Split up module-sets.conf
>
> This looks better but I think we need to find better names for the conf
> files.
The file `make/autoconf/version-numbers` is plagued by a two-fold problem:
first of all, it's a configuration file, not a part of autoconf, so it should
reside in `make/conf` instead of `make/autoconf`.
Secondly, contrary to the name, it does not only contain version numbers, but
also the
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote:
> Please review a small change that replaces use of objc_msgSend_stret in macOS
> platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
> support, where objc_msgSend_stret is not available.
Marked as reviewed by ihse
> The file `make/autoconf/version-numbers` is plagued by a two-fold problem:
> first of all, it's a configuration file, not a part of autoconf, so it should
> reside in `make/conf` instead of `make/autoconf`.
>
> Secondly, contrary to the name, it does not only contain version numbers, but
>
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`,
On Tue, 15 Dec 2020 19:19:28 GMT, Alan Bateman wrote:
>> In `Docs.gmk` there are some hard-coded links to online URL documentation
>> and bug reporting locations. These should not reside in the make file per
>> se, but instead move to the `make/conf` directory.
>
> This looks okay me to but I
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually* used by
> make for the whole build.)
>
> These data files should move
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually* used by
> make for the whole build.)
>
> These data files should move
The `templates` directory in `make` is an odd bird. It actually contains data
files that the license checker needs, so it should move to `make/data`.
-
Commit messages:
- 8258445: Move make/templates to make/data
Changes: https://git.openjdk.java.net/jdk/pull/1790/files
Webrev:
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
> since the different module sets are configured, not
On Tue, 15 Dec 2020 22:47:16 GMT, Mandy Chung wrote:
>> As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least
>> kind of a "sibling" to the others. After all, we use these sets of modules
>> together to form the set of modules for the JRE:
>>
>> JRE_MODULES += $(filter
On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie wrote:
> In `Docs.gmk` there are some hard-coded links to online URL documentation and
> bug reporting locations. These should not reside in the make file per se, but
> instead move to the `make/conf` directory.
This looks okay me to but I
> The hard-coded list of modules in `make/common/Modules.gmk` has always been a
> wart in the build system. We pride ourself on using discovery instead of
> hard-coded list. In this case, it is not possible to do do auto-discovery,
> since the different module sets are configured, not
On Tue, 15 Dec 2020 23:50:54 GMT, Mandy Chung wrote:
>> Do you see a way to get rid of `DOCS_MODULES` but determine this set at
>> build time? IIRC it was added for expediency for
>> [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312). This is
>> the set of Java SE + JDK
On Tue, 15 Dec 2020 09:20:44 GMT, Magnus Ihse Bursie wrote:
>> Yoshiki Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8257204 and 8256313
>> 8257204: Remove usage of -Xhtmlversion option from javac
>> 8256313:
The "symbol" files in make/hotspot/symbols are a list of exported symbols from
libjvm. As such, they are an essential data source for the build system, and
they should reside in make/data, not mixed with the hotspot make source code.
-
Commit messages:
- 8258449: Move
The hotspot launcher script is misplaced among the hotspot make files. It
should move to make/scripts (and get a proper extension).
-
Commit messages:
- 8258447: Move make/hotspot/hotspot.script to make/scripts
Changes: https://git.openjdk.java.net/jdk/pull/1791/files
Webrev:
On Tue, 15 Dec 2020 22:58:47 GMT, Mandy Chung wrote:
>> `JRE_TOOL_MODULES` started with more than one modules in JDK 9:
>>
>> JRE_TOOL_MODULES += \
>> jdk.jdwp.agent \
>> jdk.pack \
>> jdk.scripting.nashorn.shell \
>> #
>>
>> Since only `jdk.jdwp.agent` one module is left for
On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote:
> The hotspot launcher script is misplaced among the hotspot make files. It
> should move to make/scripts (and get a proper extension).
Can someone from hotspot please confirm if this script is still needed/used?
-
PR:
On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote:
> Hi,
>
> May I have reviews please for the following patch.
>
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler
> may be invoked instead of our error handler, and we just see a
> one-line-warning "SEH
On Tue, 15 Dec 2020 07:26:15 GMT, Yoshiki Sato wrote:
>> HTML4 is no longer supported in javadoc.
>>
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and
On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote:
> Hi,
>
> May I have reviews please for the following patch.
>
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler
> may be invoked instead of our error handler, and we just see a
> one-line-warning "SEH
On Sun, 13 Dec 2020 00:22:04 GMT, Jonathan Gibbons wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file,
On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote:
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and
On Tue, 15 Dec 2020 08:16:51 GMT, Magnus Ihse Bursie wrote:
>> Hi,
>>
>> May I have reviews please for the following patch.
>>
>> At the moment, if a crash happens on Windows in gtests, the gtest SEH
>> handler may be invoked instead of our error handler, and we just see a
>>
On Tue, 15 Dec 2020 08:20:54 GMT, Magnus Ihse Bursie wrote:
> Build changes look good.
>
> I left a note on the hotspot code; feel free to ignore it if you want. :)
>
> I agree with your assessment that restoring gtest to the code base would make
> life simpler. I'm not sure what needs to be
On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote:
> Hi,
>
> May I have reviews please for the following patch.
>
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler
> may be invoked instead of our error handler, and we just see a
> one-line-warning "SEH
37 matches
Mail list logo
