Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 23:25:28 GMT, Magnus Ihse Bursie wrote: >> @magicus Ah dang, I tested passing `--with-tools-dir` a unix path before but >> messed up the drive letter. So, passing unix path to `--with-tools-dir` >> (i.e. `--with-tools-dir='/cygdrive/j/Program Files (x86)/Microsoft Visual >>

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 22:59:23 GMT, Jorn Vernee wrote: >> @JornVernee Thanks for your feedback! I'll have a closer look at your >> examples, and see if I can reproduce them in my own environment. One >> question, your first example, was this from a Cygwin environment? >> >> As a general comment,

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 22:52:57 GMT, Magnus Ihse Bursie wrote: >> Hey, >> >> Since I often work on Windows I'm taking this for a spin, but the current >> patch fails during `configure` for me with: >> >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Vis

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 22:21:52 GMT, Jorn Vernee wrote: >> Overall this is very nice. Some comments and questions inline. > > Hey, > > Since I often work on Windows I'm taking this for a spin, but the current > patch fails during `configure` for me with: > > configure: Using default toolchain micr

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 22:21:52 GMT, Jorn Vernee wrote: >> Overall this is very nice. Some comments and questions inline. > > Hey, > > Since I often work on Windows I'm taking this for a spin, but the current > patch fails during `configure` for me with: > > configure: Using default toolchain micr

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 20:04:44 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missed my last bugfix for fixpath.sh... > > make/autoconf/util_paths.m4 line 401: > >> 399: if test

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 15:20:07 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missed my last bugfix for fixpath.sh... > > make/CreateJmods.gmk line 172: > >> 170: endif >> 171: else # not

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 21:11:19 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missed my last bugfix for fixpath.sh... > > Overall this is very nice. Some comments and questions inline. Hey,

Integrated: JDK-8257547: Handle multiple prereqs on the same line in deps files

2020-12-03 Thread Erik Joelsson
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote: > After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to hand

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Erik Joelsson
On Thu, 3 Dec 2020 15:30:15 GMT, Magnus Ihse Bursie wrote: >> For the build to work on Windows, we need a unix compatibility layer (known >> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The >> build system then needs to adapt various aspect to get the build to work in

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v2]

2020-12-03 Thread Magnus Ihse Bursie
On Mon, 30 Nov 2020 15:44:09 GMT, Erik Joelsson wrote: >> Thanks for all the comments. >> >>> - 40-50 min builds seem to be excessive for just the hotspot build, do >>> youknow what exactly takes that long? Is this for release and debug each or >>> both combined? >> >> It's for each of them.

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Magnus Ihse Bursie
> For the build to work on Windows, we need a unix compatibility layer (known > as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The > build system then needs to adapt various aspect to get the build to work in > this winenv. Over time, our current solutions (which were nev

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread Daniel D . Daugherty
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.ht

RFR: 8257679: Improved unix compatibility layer in Windows build (winenv)

2020-12-03 Thread Magnus Ihse Bursie
For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread Erik Joelsson
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.ht

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread David Holmes
On 3/12/2020 9:26 pm, Alan Bateman wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: https://docs.oracle.com/javase/8/docs/tech

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread David Holmes
On 3/12/2020 9:19 pm, Magnus Ihse Bursie wrote: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: https://docs.oracle.com/javase/8/doc

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread Alan Bateman
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.ht

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-03 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.ht

Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v3]

2020-12-03 Thread Jan Lahoda
On Tue, 1 Dec 2020 12:06:25 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java >> line 513: >> >>> 511: public java.util.List >>> l(); >>> 512:} >>> 513:""",

Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v5]

2020-12-03 Thread Jan Lahoda
> Adding support for record classes in the historical data for ct.sym. This > includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run > them. > -fixing Record attribute reading in javac's ClassReader (used for tests,