Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v10]
On Fri, 4 Mar 2022 07:51:36 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with two additional > commits since the last revision: > > - Manual revert again, I swear I'm using the correct pandoc version, I'm > confused as to why this is happening > - I think I'm beginning to hate pandoc :( Alright, I think I _finally_ managed to get pandoc working. It still ended up changing the other html files despite me using the correct version, so I had to manually revert the changes. Other than that, the generated documentation now seems to be correct when compared, and on a side note it also seems to have updated some documentation from commit https://github.com/openjdk/jdk/commit/6fab8a2d6a97dbd2ffceca275716d020cb9f1eea where someone else forgot to update the html copy of the docs. I doubt creating a new issue for that alone is worth it though - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v10]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Manual revert again, I swear I'm using the correct pandoc version, I'm confused as to why this is happening - I think I'm beginning to hate pandoc :( - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/4b921573..2b86b617 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=08-09 Stats: 1522 lines in 1 file changed: 9 ins; 1069 del; 444 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v9]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Manual rever - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/50b7e769..4b921573 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=07-08 Stats: 2181 lines in 4 files changed: 0 ins; 1185 del; 996 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v8]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Second attempt with pandoc - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/2db28c69..50b7e769 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=06-07 Stats: 3186 lines in 5 files changed: 2258 ins; 13 del; 915 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: Windows confusing object file names for other file types
Hi all, Yes, I was referring to what Magnus mentioned about the file associations. Hopefully this can be ignored, since I wasn't in a very clear state of mind when I posted this to the mailing lists :/ best regards, Julian On Fri, Mar 4, 2022 at 10:47 AM David Holmes wrote: > On 3/03/2022 11:29 pm, Julian Waters wrote: > > Windows seems to commonly confuse object file names that are created > during > > the build process > > I don't understand what you mean by that, please elaborate. > > Thanks, > David > > > , despite .obj being the normal file format for object > > files on it (Weirdly enough), which is pretty likely because of > pre-defined > > registry entries and applications that come together with it with fresh > > installs. This does sort of make it a pretty troublesome issue to solve, > > and I can't really think of any good all encompassing fix other than to > > change the object file suffix to something else (Which would be pretty > > simple to do but I don't know if that would have any unwanted side > effects > > elsewhere), I'm not sure if this is something the proposed solution would > > be ok for or if there are better ways to do this? > > > > best regards, > > Julian > > > > P.S. Windows stop being so bloated please ;-; >
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v7]
On Thu, 3 Mar 2022 16:48:40 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Revert unwanted changes Sorry for all of the noise, going to need some time to fix this issue... - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: Windows confusing object file names for other file types
On 3/03/2022 11:29 pm, Julian Waters wrote: Windows seems to commonly confuse object file names that are created during the build process I don't understand what you mean by that, please elaborate. Thanks, David , despite .obj being the normal file format for object files on it (Weirdly enough), which is pretty likely because of pre-defined registry entries and applications that come together with it with fresh installs. This does sort of make it a pretty troublesome issue to solve, and I can't really think of any good all encompassing fix other than to change the object file suffix to something else (Which would be pretty simple to do but I don't know if that would have any unwanted side effects elsewhere), I'm not sure if this is something the proposed solution would be ok for or if there are better ways to do this? best regards, Julian P.S. Windows stop being so bloated please ;-;
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v7]
On Thu, 3 Mar 2022 16:48:40 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Revert unwanted changes I suspect you used a different version of pandoc - hence the incidental changes. It also appears that the previous changes to building.md were not used to regenerate building.html. - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4]
On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote: >> The caller class returned by Reflection::getCallerClass was used to gain >> access to it's module in most cases and class loader in one case. I added a >> method to translate the caller class to caller module so that the decision >> of what module represents the caller with no stack frame is made in a single >> place. Calls made to caller.getModule() were replaced with >> getCallerModule(caller) which returns the system class loader unnamed module >> if the caller is null. >> >> The one place a class loader was produced from the caller in getBundleImpl >> it was rewritten to route through the getCallerModule method: >> >> final ClassLoader loader = (caller != null) ? >> caller.getClassLoader() : getLoader(getCallerModule(caller)); >> >> A JNI test was added which calls getBundle to fetch a test bundle from a >> location added to the classpath, fetches a string out of the bundle and >> verifies it, and calls clearCache. >> >> The javadoc was updated for the caller sensitive methods changed. > > Tim Prinzing has updated the pull request incrementally with one additional > commit since the last revision: > > more suggested changes Marked as reviewed by mchung (Reviewer). src/java.base/share/classes/java/util/ResourceBundle.java line 1570: > 1568: Module callerModule = (caller != null) ? caller.getModule() > 1569: : ClassLoader.getSystemClassLoader().getUnnamedModule(); > 1570: return callerModule; nit: `callerModule` variable is not needed. It can simply do: return (caller != null) ? caller.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); - PR: https://git.openjdk.java.net/jdk/pull/7663
Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4]
> The caller class returned by Reflection::getCallerClass was used to gain > access to it's module in most cases and class loader in one case. I added a > method to translate the caller class to caller module so that the decision of > what module represents the caller with no stack frame is made in a single > place. Calls made to caller.getModule() were replaced with > getCallerModule(caller) which returns the system class loader unnamed module > if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it > was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a > location added to the classpath, fetches a string out of the bundle and > verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: more suggested changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7663/files - new: https://git.openjdk.java.net/jdk/pull/7663/files/eeb2d0fa..45f9b37b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7663=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7663=02-03 Stats: 31 lines in 2 files changed: 2 ins; 13 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v7]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert unwanted changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/a19ce21b..2db28c69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=05-06 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v6]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Make configure warning more accurate - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/c652b2fc..a19ce21b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=04-05 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v4]
On Thu, 3 Mar 2022 15:54:44 GMT, Magnus Ihse Bursie wrote: >> Would it be better if I changed that to say the flags are misleading, or if >> I reverted it back to legacy in that case? (Since that seems to be the >> primary concern with using them) > > As the build documentation says, the standard autoconf tripled was created > for building Canadian cross compilers (i.e. cross-compiling a > cross-compiler). This means that they use "host" for what we call "target", > and they use "target" for something that is not relevant for us. This caused > a lot of confusion early on when OpenJDK started using autoconf. > > If you know what you are doing, there's nothing inherently *wrong* with using > the autoconf triplet. It's just confusing, due to the name clash of "target". > > If you think this is not clear enough from the documenation and need to add > something to the warnings printed by the configure wrapper, sure, go ahead > and add a line about how this can be confusing. > > But it is not unsafe. Alright, will change accordingly, thanks for the review - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v5]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: html finally decided to goddamn work - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/1d398962..c652b2fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=03-04 Stats: 2035 lines in 5 files changed: 3 ins; 0 del; 2032 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v4]
On Thu, 3 Mar 2022 08:12:37 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Syntax Managed to get pandoc to work, but it seems to have changed other html files as well. I'm not sure what caused this- I haven't modified the other markdown files at all - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v4]
On Thu, 3 Mar 2022 13:32:33 GMT, Julian Waters wrote: >> make/autoconf/configure line 298: >> >>> 296: exit 1 >>> 297: else >>> 298: echo "Warning: You are using unsafe autoconf cross-compilation >>> flags." >> >> The autoconf flags are not really unsafe, they are just misleadingly named. >> I'd rather see that you restore "legacy" in this output, and the >> conf_legacy_crosscompile variable name. > > Would it be better if I changed that to say the flags are misleading, or if I > reverted it back to legacy in that case? (Since that seems to be the primary > concern with using them) As the build documentation says, the standard autoconf tripled was created for building Canadian cross compilers (i.e. cross-compiling a cross-compiler). This means that they use "host" for what we call "target", and they use "target" for something that is not relevant for us. This caused a lot of confusion early on when OpenJDK started using autoconf. If you know what you are doing, there's nothing inherently *wrong* with using the autoconf triplet. It's just confusing, due to the name clash of "target". If you think this is not clear enough from the documenation and need to add something to the warnings printed by the configure wrapper, sure, go ahead and add a line about how this can be confusing. But it is not unsafe. - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3]
On Wed, 2 Mar 2022 22:21:03 GMT, Mandy Chung wrote: >> Tim Prinzing has updated the pull request incrementally with one additional >> commit since the last revision: >> >> suggested changes > > test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c > line 28: > >> 26: >> 27: #include "jni.h" >> 28: #undef NDEBUG > > is this line unintended? Forcing the assert() seems like a good idea in a test - PR: https://git.openjdk.java.net/jdk/pull/7663
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v4]
On Thu, 3 Mar 2022 13:16:08 GMT, Magnus Ihse Bursie wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Syntax > > make/autoconf/configure line 298: > >> 296: exit 1 >> 297: else >> 298: echo "Warning: You are using unsafe autoconf cross-compilation >> flags." > > The autoconf flags are not really unsafe, they are just misleadingly named. > I'd rather see that you restore "legacy" in this output, and the > conf_legacy_crosscompile variable name. Would it be better if I changed that to say the flags are misleading, or if I reverted it back to legacy in that case? (Since that seems to be the primary concern with using them) - PR: https://git.openjdk.java.net/jdk/pull/7656
Windows confusing object file names for other file types
Windows seems to commonly confuse object file names that are created during the build process, despite .obj being the normal file format for object files on it (Weirdly enough), which is pretty likely because of pre-defined registry entries and applications that come together with it with fresh installs. This does sort of make it a pretty troublesome issue to solve, and I can't really think of any good all encompassing fix other than to change the object file suffix to something else (Which would be pretty simple to do but I don't know if that would have any unwanted side effects elsewhere), I'm not sure if this is something the proposed solution would be ok for or if there are better ways to do this? best regards, Julian P.S. Windows stop being so bloated please ;-;
Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v4]
On Thu, 3 Mar 2022 08:12:37 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Syntax This is looking much better. Apart from the "unsafe" comment, the only thing remaining is that you update building.html by running `make update-build-docs`. make/autoconf/configure line 298: > 296: exit 1 > 297: else > 298: echo "Warning: You are using unsafe autoconf cross-compilation > flags." The autoconf flags are not really unsafe, they are just misleadingly named. I'd rather see that you restore "legacy" in this output, and the conf_legacy_crosscompile variable name. - Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Add option to explicitly set build platform and remove support for legacy cross compilation flags [v4]
On Thu, 3 Mar 2022 08:12:37 GMT, Julian Waters wrote: >> Currently the only other option for manually configuring the build platform >> while cross compiling are devkits, which don't work on certain systems and >> are also more focused on differentiating the build and target compilers >> instead. This patch adds the ability to explicitly set the build platform >> through a new option, which can be especially helpful for when autodetection >> fails and devkits cannot be relied on, and also for simpler cross >> compilation cases (Like the one described in building.md) >> >> This also removes support for the legacy cross compilation flags as well. >> >> WIP: Translation from markdown to html > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Syntax Updated accordingly, html version of the docs is still WIP (Some trouble on my end with `make update-build-docs`) - PR: https://git.openjdk.java.net/jdk/pull/7656
Re: RFR: JDK-8282532: Add option to explicitly set build platform and remove support for legacy cross compilation flags [v4]
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > This also removes support for the legacy cross compilation flags as well. > > WIP: Translation from markdown to html Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Syntax - Changes: - all: https://git.openjdk.java.net/jdk/pull/7656/files - new: https://git.openjdk.java.net/jdk/pull/7656/files/9189e54b..1d398962 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7656=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7656=02-03 Stats: 13 lines in 2 files changed: 1 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7656/head:pull/7656 PR: https://git.openjdk.java.net/jdk/pull/7656
