Re: fixpath seems to be deleting path separators when paths are read from files

M Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > > On 2022-04-13 05:39, Julian Waters wrote: > > Recently I've been getting build failures on my Windows device that go > > something along the lines of: > > > /msys64/ucrt64/bin/../lib

fixpath seems to be deleting path separators when paths are read from files

Recently I've been getting build failures on my Windows device that go something along the lines of: /msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe: cannot find

Integrated: JDK-8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name

On Thu, 17 Mar 2022 13:11:19 GMT, Julian Waters wrote: > TOOLCHAIN_SETUP_MSVC_DLL always points to --with-msvcr-dll if it couldn't > find the requested file, even if the dll being searched for was msvcp.dll for > instance. This small patch fixes the potentially confusing advice

RFR: JDK-8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name

TOOLCHAIN_SETUP_MSVC_DLL always points to --with-msvcr-dll if it couldn't find the requested file, even if the dll being searched for was msvcp.dll for instance. This small patch fixes the potentially confusing advice to point to the correct options - Commit messages: -

Re: Supporting alternative toolchains on Windows

Attached to this thread is related information I could find within the JVM's build system (Posted to the top level to not clutter the discussion below) Information currently gathered by simply disabling Visual C++ and link.exe specific flags if gcc is detected until build failure. Also had to

Re: Supporting alternative toolchains on Windows

I meant in toolchain.m4, which allows gcc for macOS best regards, Julian On Sat, Mar 12, 2022 at 4:32 AM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2022-03-11 20:02, Julian Waters wrote: > > I understand the concerns, seems like I grossly underestimated t

Re: Supporting alternative toolchains on Windows

< magnus.ihse.bur...@oracle.com> wrote: > > > On 2022-03-11 14:34, Julian Waters wrote: > > Darn, seems like it'll be much harder than I expected. Since multiple > toolchains are supported for macOS and Linux, I assumed a slight patch > would help get it to work on Windows. Lookin

Re: Supporting alternative toolchains on Windows

by side on the off chance this becomes a reality though best regards, Julian On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2022-03-11 12:55, Julian Waters wrote: > > > Hi all, > > > > How feasible would it b

Supporting alternative toolchains on Windows

Hi all, How feasible would it be/much effort would it require to support compiling with alternate toolchains on Windows besides Visual C++ (like the Windows ports of clang and gcc) if we restrict the allowed toolchains to only those that link against the ucrt? (Toolchains linking against the

Integrated: JDK-8282700: Properly handle several --without options during configure

On Sat, 5 Mar 2022 12:44:36 GMT, Julian Waters wrote: > Some of the --without options are not properly handled and will crash when > processed (For example, --without-version-string), in other cases the > --without-* option will actually silently produce incorrect result

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v6]

oesn't make sense to pass said option however, it should display > a warning instead of letting configure exit with a confusing error when it's > run Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrela

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v5]

oesn't make sense to pass said option however, it should display > a warning instead of letting configure exit with a confusing error when it's > run Julian Waters has updated the pull request incrementally with one additional commit since the last revision: MACOSX_

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 11:54:13 GMT, Magnus Ihse Bursie wrote: >> I treated this differently since it didn't seem to have any default value at >> all, as opposed to the other vendor options. I may have made a mistake while >> looking for where the vendor version string is defined in this case > >

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 11:57:13 GMT, Magnus Ihse Bursie wrote: >> Got it, should I link JDK-8282948 into this PR while addressing this issue >> in the meantime? >> (On a side note the macOS tier 1 tests are also failing after this change, >> so you may be right that the build will inevitably fail

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 11:42:05 GMT, Magnus Ihse Bursie wrote: >> Both version build and version opt have valid --without options though, if >> both are set (As in the case of an adhoc build run with >> --without-version-opt) that could be problematic, since the issue wouldn't >> be stemming

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 09:40:13 GMT, Magnus Ihse Bursie wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix syntax errors > > make/autoconf/jdk-version.m4 line 507: > >&g

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 09:58:29 GMT, Magnus Ihse Bursie wrote: >> From what I can tell, wouldn't MACOSX_BUNDLE_BUILD_VERSION be an empty >> string anyway if both VERSION_BUILD and VERSION_OPT = ""? > > That might be. If that is so, then you've most likely spotted a bug. In > practice, you're

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

On Thu, 10 Mar 2022 09:41:32 GMT, Magnus Ihse Bursie wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix syntax errors > > make/autoconf/jdk-version.m4 line

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v4]

oesn't make sense to pass said option however, it should display > a warning instead of letting configure exit with a confusing error when it's > run Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Fix syntax errors --

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v3]

oesn't make sense to pass said option however, it should display > a warning instead of letting configure exit with a confusing error when it's > run Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Fold --w

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v2]

On Tue, 8 Mar 2022 14:02:35 GMT, Magnus Ihse Bursie wrote: >> I'm of the opinion that options which cannot have empty values, and will >> fall back to default ones if no explicit one is provided, would generate an >> error if --without-* is passed, while others that _can_ have empty values >>

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v2]

On Tue, 8 Mar 2022 04:15:51 GMT, David Holmes wrote: > Passing --without-x makes no sense at all IMHO. Even so, I'd argue that it should be handled properly and show what really went wrong, rather than throwing, for instance, "no is not a valid version string" (In the case of

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v2]

On Mon, 7 Mar 2022 19:54:17 GMT, Magnus Ihse Bursie wrote: >> I think this, even more, makes it clear that `--without-vendor-url` can´t >> possible be meant to be interpreted as "use https://openjdk.java.net/;. >> >> Basically, I think what I'm arguing for is that we can fold this check into

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson wrote: > > Should I change the JBS issue title to match the PR title, or is it > > preferred for the PR title to change? > > They need to match. You can either do it manually, or change the title to > just the bug number and the bot will change

Re: RFR: JDK-8282700: Properly handle several --without options during configure [v2]

oesn't make sense to pass said option however, it should display > a warning instead of letting configure exit with a confusing error when it's > run > > This is an initial change and I may have missed several options; I'll double > check and make sure in the meantime Julian Wate

RFR: JDK-8282700: Properly handle several --without options during configure

Some of the --without options are not properly handled and will crash when processed (For example, --without-version-string), in other cases the --without-* option will actually silently produce incorrect results instead of actually doing what --without-* implies (For example,

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice, good work matteo Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > Hi > > I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. > Now: what is the next step? > >

Re:

t; It's not clear to me if this is a feasible proposal. > > /Erik > > On 2022-03-04 07:46, Julian Waters wrote: > > Hi Magnus, > > > > While looking through the now resolved JDK-8274980 > > <https://bugs.openjdk.java.net/browse/JDK-8274980> one discussed >

[no subject]

Hi Magnus, While looking through the now resolved JDK-8274980 one discussed possibility in particular caught my eye: "The one thing remaining now to make me fully happy wrt version numbers, is if we could stop hard-coding them into files during

Integrated: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target

On Wed, 2 Mar 2022 08:11:51 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

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v11]

et 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

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 an

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 an

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v10]

et 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

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v9]

et 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

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v8]

et 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

Re: Windows confusing object file names for other file types

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 t

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 an

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v7]

et 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

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v6]

et 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

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

Re: RFR: JDK-8282532: Allow explicitly setting build platform alongside --openjdk-target [v5]

et 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

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 an

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 >&g

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

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 an

Re: RFR: JDK-8282532: Add option to explicitly set build platform and remove support for legacy cross compilation flags [v4]

s 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://g

Re: RFR: JDK-8282532: Add option to explicitly set build platform and remove support for legacy cross compilation flags [v3]

s 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: Don't perform autodetection if --build is specified - Changes: - all: https://git.openjdk.jav

Re: RFR: JDK-8282532: Add option to explicitly set build platform and remove support for legacy cross compilation flags [v2]

s 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: Adopt better solution for processing provided flags - Changes: - all: https://git.openjdk.jav