The documentation for build performance currently points to the non-existent
--enable-sjavac flag to enable sjavac, the correct one is actually
--enable-javac-server (Finally seem to have gotten pandoc working, hopefully
the html is correct this time)
-
Commit messages:
- Correct
On Mon, 20 Jun 2022 13:01:40 GMT, Julian Waters wrote:
> The documentation for build performance currently points to the non-existent
> --enable-sjavac flag to enable sjavac, the correct one is actually
> --enable-javac-server (Finally seem to have gotten pandoc working, hopefully
&
On Mon, 4 Jul 2022 07:04:40 GMT, ScientificWare wrote:
> This is tracked in JBS as
>
> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741)
>
>> **Remove unused imports from DTDBuilder.java**
> Some imports are no more used.
>
> - java.io.FileNotFoundException;
> - java.io.BufferedInputS
On Tue, 5 Jul 2022 03:40:51 GMT, Julian Waters wrote:
>> This is tracked in JBS as
>>
>> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741)
>>
>>> **Remove unused imports from DTDBuilder.java**
>> Some imports are no more used.
Sorry if this sounds like a bit of a silly question, but what's the
difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal),
and, say, the regular Server VM the build system generates by default? All
it seems to do is define MINIMAL_JVM (Which doesn't seem to be used
anywhere?), s
Sorry if this sounds like a bit of a silly question, but what's the
difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal),
and, say, the regular Server VM the build system generates by default? All
it seems to do is define MINIMAL_JVM (Which doesn't seem to be used
anywhere?), s
e stage, see
> https://github.com/openjdk/jdk/blob/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4/make/autoconf/jvm-features.m4#L422-L425
>
> That typically manifests via flags like -DINCLUDE_CDS=0,
> see hotspot/lib/JvmFeatures.gmk
>
> HTH, Cheers, Thomas
>
>
> On Tue, Jul 12,
On Fri, 15 Jul 2022 13:25:57 GMT, Jorn Vernee wrote:
> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on
> Windows/MSVC. Instead of fixing all warnings that were produced from this,
> I've instead locally disabled the warning in the files that produced
> warnings. This al
Found something interesting in FLAGS_SETUP_STRIPFLAGS recently:
## Setup strip.
# FIXME: should this really be per platform, or should it be per toolchain
type?
# strip is not provided by clang; so guessing platform makes most sense.
STRIPFLAGS is set to -S after this for clang (or more accurately
IPFLAGS based on probing the strip executable that was found.
>
> /Erik
>
> On 7/24/22 1:07 AM, Julian Waters wrote:
> > Found something interesting in FLAGS_SETUP_STRIPFLAGS recently:
> > ## Setup strip.
> > # FIXME: should this really be per platform, or should it be pe
CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined,
but empty macro in libjli if it is not defined in the build system, which is
incorrect
-
Commit messages:
- Add missing check in JLI macro definitions
Changes: https://git.openjdk.org/jdk/pull/9669/file
27/22 7:46 PM, Julian Waters wrote:
>
> What would be a good way to test for the strip executable? The easiest
> solution off the top of my head is to assume a particular compiler uses a
> particular strip, but that sounds a little too inflexible.
>
> Maybe assuming based on toolchai
On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote:
> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a
> defined, but empty macro in libjli if it is not defined in the build system,
> which is incorrect
Comment to keep thread alive
-
> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a
> defined, but empty macro in libjli if it is not defined in the build system,
> which is incorrect
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The increment
On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote:
> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a
> defined, but empty macro in libjli if it is not defined in the build system,
> which is incorrect
Merged with latest, currently awaiting further revi
On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote:
> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a
> defined, but empty macro in libjli if it is not defined in the build system,
> which is incorrect
This pull request has now been integrated.
Changeset:
The support for Link Time Optimization in the JDK's make system could do with
some cleaning up, at the moment it simply assumes the compiler is gcc and sets
the flags as such. Instead of introducing changes in bulk, as a first step, it
would be good to simply supply the appropriate flags dependi
On Thu, 5 Oct 2023 15:12:06 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensio
On Mon, 9 Oct 2023 09:03:08 GMT, Frederic Thevenet
wrote:
>> make/CreateJmods.gmk line 83:
>>
>>> 81: ifneq ($(CMDS_DIR), )
>>> 82: DEPS += $(call FindFiles, $(CMDS_DIR))
>>> 83: ifeq ($(call isTargetOs, windows)+$(SHIP_DEBUG_SYMBOLS), true+public)
>>
>> Suggestion:
>>
>> ifeq ($(call i
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensio
On Mon, 9 Oct 2023 12:51:16 GMT, Erik Joelsson wrote:
>> I understand the point of this change, but it is not directly related to the
>> issue addressed here (i.e. this condition wasn't introduced in this PR.).
>> Should it be included in the PR anyway?
>
> I agree with @fthevenet, such a change
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensio
On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with five additional
commits since the last revision:
- Revert sspi.cpp
- Revert NativeCreds.c
- Revert allocation.cpp
- Revert symbolengine.cpp
- Revert os_windows.cpp
-
Changes:
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensio
On Tue, 10 Oct 2023 03:44:27 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Don't use permissive- in flags-cflags.m4 for now
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: htt
On Wed, 25 Oct 2023 13:07:18 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensi
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
Keeping alive
-
PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1785145814
On Mon, 30 Oct 2023 15:08:03 GMT, Julian Waters wrote:
>> Prepare HotSpot for the permissive- Visual C++ flag, this change contains
>> all of the fixes required for HotSpot to compile under the stricter mode
>> activated when the permissive- flag is passed
>&g
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
permissive- positioning flags-cflags.m4
-
Changes:
- all: https:
On Tue, 31 Oct 2023 07:32:35 GMT, Kim Barrett wrote:
>> I know he was away until October but not exactly when in October.
>
> Ick! I hadn't followed https://github.com/openjdk/jdk/pull/15096 closely, so
> hadn't noticed the discussion there. Not sure why this is using a literal 0
> rather than `
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
InterceptOSException should not use negation in os_windows.cpp
-
Chan
On Fri, 6 Oct 2023 05:14:18 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Initialized thread in os_windows.cpp
>> - Oops in os_windows.cpp
>> - Rem
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Formatting os_windows.cpp
- Duplicate return statement instead in os_windo
On Wed, 1 Nov 2023 11:19:20 GMT, Julian Waters wrote:
>> Prepare HotSpot for the permissive- Visual C++ flag, this change contains
>> all of the fixes required for HotSpot to compile under the stricter mode
>> activated when the permissive- flag is passed
>&g
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Try immediate bailout in os_windows.cpp
-
Changes:
- all: https:
On Thu, 2 Nov 2023 05:34:00 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Try immediate bailout in os_windows.cpp
>
> src/hotspot/os/windows/os_windows.cpp l
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert goto in os_windows.cpp
-
Changes:
- all: https://git.o
ix under discussion)
> - Removed a throw() specification from a mismatched definition in
> allocation.cpp
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
os_windows.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15
On Thu, 28 Sep 2023 03:22:30 GMT, Julian Waters wrote:
> Prepare HotSpot for the permissive- Visual C++ flag, this change contains all
> of the fixes required for HotSpot to compile under the stricter mode
> activated when the permissive- flag is passed
>
> -
Hi,
I can help you, how should I create the issue?
best regards,
Julian
I do believe the voting time for this has been over for quite a while :P
best regards,
Julian
This question was brought up in https://github.com/openjdk/jdk/pull/15096,
the issue is that awt.dll has historically tried to avoid depending on
msvcp.dll, and as
https://github.com/openjdk/jdk/pull/15096#issuecomment-1796303631 points
out, it is unclear whether it is now safe to introduce a depen
On Thu, 16 Nov 2023 17:09:25 GMT, Magnus Ihse Bursie wrote:
> From the bug report: Building.md file contains a number of HTTP links that
> would need to be converted to HTTPS in order for clicking on the links on the
> OpenJDK web site at https://openjdk.org/groups/build/doc/building.html to
>
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 78 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-development community edition.
>
> Cla
On Fri, 8 Dec 2023 09:46:59 GMT, Daniel Jeliński wrote:
> > Is it possible to fold clang-cl into the microsoft toolchain instead, and
> > just pass clang-cl as the compiler instead of cl?
>
> I suppose it's possible; clang-cl output is supposed to be compatible with
> link & lib, and most comm
On Fri, 8 Dec 2023 23:17:29 GMT, Magnus Ihse Bursie wrote:
> > > we need to design the integration of clang-cl in a way that we can
> > > (hopefully) reuse existing clang warning disables.
> >
> >
> > I'd love that. Got any preferences on how that should be handled?
>
> Not straight out of my
On Fri, 15 Dec 2023 07:48:46 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. Th
On Fri, 15 Dec 2023 08:03:45 GMT, Julian Waters wrote:
>> src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 77:
>>
>>> 75: #define read_csr(csr) \
>>> 76: ({
On Fri, 15 Dec 2023 09:05:37 GMT, Kim Barrett wrote:
>> There are, strangely, many more register keywords in the JDK codebase than
>> just this one, but none of them throw the same errors, only this one does
>
> Looks like this change has also already been made, by JDK-8319440.
>
> All of the o
On Fri, 15 Dec 2023 12:31:51 GMT, Kim Barrett wrote:
>> Ah, I was not aware that the asm specifications for explicit registers
>> overrides the warning about the register keyword, thanks!
>
> It's not that it overrides the warning. They are different syntactic
> constructs that just happen to
On Fri, 15 Dec 2023 12:56:07 GMT, Julian Waters wrote:
>> It's not that it overrides the warning. They are different syntactic
>> constructs that just happen to have
>> a word in common. The joys of parsing C++ ...
>
> The keyword also happens to go in t
> Compile the JDK as C++17, enabling the use of all C++17 language features
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains se
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
> So why is "-std=gnu++11" being used at all?
autoconf has a heuristic that automatically checks "For compiler flags
required to enable C++11 for the current compiler", and if the check
passes, autoconf automatically adds -std=gnu++11 to the CFLAGS. Something
is likely (wrongly) tripping this heur
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out any -std* flags added
> by autoconf from CC/CXX .
>
On Wed, 10 Jan 2024 01:58:33 GMT, Kim Barrett wrote:
> Please review this change to enable -Wparentheses when building HotSpot. That
> warning is enabled by -Wall (which we use). That was overridden by explicitly
> disabling it, because there were a number of places in HotSpot code that
> trigger
On Wed, 10 Jan 2024 07:44:47 GMT, Matthias Baesken wrote:
> That might be a bit tricky, because on my macOS test machine, with a self
> compiled autoconf 2.72, I did not even get this strange behavior. But it was
> a different macOS version . So it seems to be a problem of very specific
> envi
> Compile the JDK as C++17, enabling the use of all C++17 language features
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains ei
> Compile the JDK as C++17, enabling the use of all C++17 language features
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Remove unnecessary -std=c++17 option in Lib.gmk
-
Changes:
- all: https://git.openjdk.
On Wed, 10 Jan 2024 13:53:47 GMT, Matthias Baesken wrote:
> Hi Martin, probably we can update our devkit if really needed. But
> https://clang.llvm.org/cxx_status.html states that c++17 is supported for a
> very long time, so probably clang 13.1 is sufficient too (or is there a real
> showstop
code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 79 commits:
- Merge branch 'openjdk:master' into patch-10
- Merge branch 'openjdk:master' into pa
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Thu, 11 Jan 2024 12:11:17 GMT, Magnus Ihse Bursie wrote:
> What is remaining to get this PR committable? It has such a long history that
> it is hard to get a grasp on the remaining issues.
>
> @TheShermanTanker Could you perhaps summarize the remaining hurdles?
It's largely complete by now
On Thu, 11 Jan 2024 12:47:25 GMT, Martin Doerr wrote:
> @TheRealMDoerr The adlc build is notoriously problematic, since it does not
> share the common flags set for JVM or JDK native compilation. :( So your
> suggestion sounds highly likely to me. Running with LOG=cmdlines will confirm
> this.
On Thu, 11 Jan 2024 12:58:43 GMT, Magnus Ihse Bursie wrote:
> There is a typo in adlc:
>
> ```
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk
> b/make/hotspot/gensrc/GensrcAdlc.gmk
> index 0898d91e1c2..bb356476847 100644
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/
> Compile the JDK as C++17, enabling the use of all C++17 language features
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Require clang 13 in toolchain.m4
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14
On Fri, 12 Jan 2024 11:35:48 GMT, Magnus Ihse Bursie wrote:
> The grep fixes are excellent, thank you for those!
>
> The CXX filtering is a hack, and I'm slightly less happy about that. Otoh,
> the entire autoconf compiler detection stuff is so-so, and we're basically
> trying to avoid getting
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>> added by autoconf from CXX
[JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
autoconf flags being added to the command line, and solves the issue by
filtering out the added flags by force. This is not optimal however, as doing
so leaves the autoconf message that the flags were added still display
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request incrementally with one additional
On Fri, 12 Jan 2024 16:04:20 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make/autoconf/toolchain.m4
>>
>> Co-authored-by: Magnus Ihse Bursie
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
On Sun, 14 Jan 2024 03:59:59 GMT, Jan Kratochvil
wrote:
> Similar to JDK-8309287.
If building.md is modified, building.html also has to be refreshed by running
make update-build-docs
-
PR Comment: https://git.openjdk.org/jdk/pull/17415#issuecomment-1891327712
On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race wrote:
>> I happened to ask around on the build-dev mailing lists about whether we
>> include msvcp.dll with the JDK, here is Erik's response:
>>
>>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
>>> msvcp*.dll. This changed when
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request with a new target base due to a
m
On Wed, 17 Jan 2024 12:08:18 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request incrementally with two additional
c
On Wed, 17 Jan 2024 14:15:02 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
On Thu, 18 Jan 2024 07:37:11 GMT, Magnus Ihse Bursie wrote:
> Then it sounds like this is not a viable approach.
There's definitely gotta be a way to make autoconf do what we want that's out
there, I'll work on it and post any findings back here. I've just found out
that the implicit calls to
On Thu, 18 Jan 2024 09:23:24 GMT, Magnus Ihse Bursie wrote:
> > (Sometimes I wonder whether Java could've gone the way V8 went and used
> > Python or Java itself as the build system instead, oh well)
>
> While I think we're stuck with make for the long run, a long-term goal for me
> has been (
On Thu, 18 Jan 2024 13:59:30 GMT, Erik Joelsson wrote:
> > What fun, I just found out that omitting the call to AC_PROG_CC and
> > AC_PROG_CXX has no effect, and they're _still_ called magically from
> > somewhere by autoconf even if you don't call them. I'm genuinely at a loss
> > for words :
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request incrementally with one additional
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request incrementally with one additional
s were added still displaying
> during the configure process, which is confusing. Instead, setting a couple
> of fields to disable the autoconf internals responsible for the unwanted flag
> is a cleaner solution
Julian Waters has updated the pull request incrementally with one additional
Vote: yes
best regards,
Julian
Well, there's a certain individual that can help out if need be ;)
best regards,
Julian
On Fri, Jan 19, 2024 at 6:46 AM Magnus Ihse Bursie
wrote:
>
> On 2024-01-18 10:44, Julian Waters wrote:
>
> If I understand you correctly, this new hypothetical system would replace
&
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal how
code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- awt_Component.cpp
- awt_Canvas.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org/jdk/pull/15096
On Sun, 21 Jan 2024 07:55:13 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 84 commits:
- Merge branch 'openjdk:master' into patch-10
- awt_Window.cpp
- awt_Frame.cpp
- awt_Component.cpp
- awt_C
1 - 100 of 802 matches
Mail list logo
