On Thu, 17 Aug 2023 08:38:01 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 Tue, 5 Sep 2023 15:51:58 GMT, Saint Wesonga wrote:
> Set MSVC source and execution character sets to UTF-8 to enable Visual C++ to
> compile all source files regardless of the active code page on Windows. This
> avoids build errors due to "warning C4819: The file contains a character that
ve 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 25 commits:
- Merge branch 'master' into patch-10
- Document changes in awt_DnDDS.cpp
- Remove negation in os_windows.cpp
- Mismatc
On Thu, 17 Aug 2023 08:38:01 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
Perhaps we could direct developers to look for the *** Waiting for
unfinished jobs message in build.log as well, since that typically
occurs extremely close to the error site?
Also, hi Magnus! It's been quite a while! :D
best regards,
Julian
Hi all,
This is just a test message, please ignore
~Julian
On Tue, 5 Sep 2023 22:59:27 GMT, Erik Joelsson wrote:
> Tests on Linux (and I assume other unix like OSes) are built with debug
> enabled and debug symbols internal. On Windows and macos, internal debug
> symbols aren't possible, and we have for some reason hard coded not including
> the
On Fri, 1 Sep 2023 21:08:53 GMT, Erik Joelsson wrote:
> Compiling the ADLC build tool on Windows is generating multiple warnings like
> this:
>
> cl : Command line warning D9007 : '/pathmap:' requires
> '/experimental:deterministic'; option ignored
>
> This is caused by the `ADLC_CFLAGS` are
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
iscussion)
> - 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
-
Changes:
- a
iscussion)
> - 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_windows.cpp
--
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
>
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
>&
iscussion)
> - 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://git.open
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
iscussion)
> - 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.openjdk.org
iscussion)
> - 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/15955/files
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
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
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
>
iscussion)
> - 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://git.open
On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
>>
>> Other than
On Tue, 19 Sep 2023 07:02:32 GMT, Daniel Jeliński wrote:
>> WinHTTP functions are only used when an application:
>> - uses DefaultProxySelector to resolve proxies, and
>> - is run with -Djava.net.useSystemProxies=true
>>
>> In all other cases, loading winhttp.dll is a waste of resources.
>>
>>
On Thu, 14 Sep 2023 03:23:55 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Document changes in awt_DnDDS.cpp
>
> Pinging
> @TheShermanTanker In my experienc
On Fri, 29 Sep 2023 17:52:32 GMT, Ludvig Janiuk wrote:
> make/conf/jib-profiles.js passes JT_JAVA in the testOnlyProfiles. This can be
> used to control jtreg's launcher script, but we don't launch that way
> anymore, we launch jtreg directly using jtreg.jar. Therefore this is dead
> code and
On Fri, 29 Sep 2023 10:01:42 GMT, Daniel Jeliński wrote:
> Please review this patch that reenables `delete-null-pointer-checks`
> optimization in GCC and Clang.
>
> It also disables `nonnull-compare` warning that is now triggered in debug
> builds. The problematic code will be addressed by
On Mon, 2 Oct 2023 08:26:34 GMT, Daniel Jeliński wrote:
>> Please review this patch that reenables `delete-null-pointer-checks`
>> optimization in GCC and Clang.
>>
>> It also disables `nonnull-compare` warning that is now triggered in debug
>> builds. The problematic code will be addressed
On Mon, 2 Oct 2023 11:09:43 GMT, Daniel Jeliński wrote:
>> make/autoconf/flags-cflags.m4 line 928:
>>
>>> 926: FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_LIFETIME_DSE_CFLAG],
>>> 927: PREFIX: $2, IF_FALSE: [NO_LIFETIME_DSE_CFLAG=""])
>>> 928: $1_GCC6_CFLAGS=${NO_LIFETIME_DSE_CFLAG}
ve 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 26 commits:
- Merge branch 'openjdk:master' into patch-10
- Merge branch 'master' into patch-10
- Document changes in awt_DnDD
On Tue, 1 Aug 2023 01:52:24 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 Visual C compiler much le
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
On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
>>
>> Other than
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
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
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
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
ve 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: https://
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
ve 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
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
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
On Thu, 17 Aug 2023 08:38:01 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 Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote:
> GHA regularly breaks because we specify a very explicit GCC version, even
> down to the release versioning of the Ubuntu package. In just this last
> week, it has caused issues with the testing of PRs on 11u
>
On Mon, 14 Aug 2023 20:57:24 GMT, Phil Race wrote:
> I have no time to look at the client changes for quite some time so do not
> push it. No matter how many other people approve it. And in the meantime you
> can (1) explain how many client tests you ran - and it had better be all of
> them
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)
The minimum compiler requirements have not been implemented yet, as I wanted to
leave their discretion to any reviewers
Implementation of [JEP draft: Compile the JDK as
C++17](https://bugs.openjdk.org/browse/JDK-8310260)
-
Commit messages:
- vm_version_linux_riscv.cpp
- allocation.cpp
- 8310260
Changes: https://git.openjdk.org/jdk/pull/14988/files
Webrev:
On Wed, 16 Aug 2023 19:22:01 GMT, Sergey Bylokhov wrote:
> Why initial patch was reverter using this comment: "unfortunately, did not
> prove to be as useful as expected"? What was the problem? What about the
> "pedantic" option which was added last time?
Hi, the problem was that gcc and
On Thu, 17 Aug 2023 08:38:01 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
ve code quality on Windows in the future. It can be done with some
> effort, given that the significantly stricter gcc can now compile an
> experimental Windows JDK as of 2023, and will serve to significantly cut down
> on monstrosities in ancient Windows code
Julian Waters has
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)
Hi Andrew, majority of the work to remove C++17 breaking code from the JDK is
actually already complete, this PR cleans out th
On Thu, 17 Aug 2023 08:38:01 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, 10 Aug 2023 04:04:58 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). It can be done
>>
On Tue, 29 Aug 2023 00:16:46 GMT, Erik Joelsson wrote:
> On Windows, when a directory exists in the "unix" root with the same name as
> a directory in the "test" dir, fixpath will corrupt test arguments to jtreg
> (and possibly other arguments as well). Fixpath sees a string like this:
>
>
On Tue, 29 Aug 2023 00:16:46 GMT, Erik Joelsson wrote:
> On Windows, when a directory exists in the "unix" root with the same name as
> a directory in the "test" dir, fixpath will corrupt test arguments to jtreg
> (and possibly other arguments as well). Fixpath sees a string like this:
>
>
I do believe the voting time for this has been over for quite a while :P
best regards,
Julian
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
&
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?),
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?),
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;
> -
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
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:
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
S 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 per
> >
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 toolchain is go
On an even closer inspection, the strip used currently on MacOS is actually
XCode strip and not the one that comes with LLVM, do we already have an
XCode check that can be piggybacked off at the moment?
best regards,
Julian
On Tue, Aug 2, 2022 at 1:30 PM Julian Waters
wrote:
> After a qu
On Thu, 11 Aug 2022 04:18:58 GMT, Julian Waters wrote:
> 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, a
o difference between
> specifying them from make and in a source file. The easiest solution is to
> just always link them from make and remove any source level linkage.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
On Sun, 16 Oct 2022 13:18:14 GMT, Alan Bateman wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update Guid.cpp
>
> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line
o difference between
> specifying them from make and in a source file. The easiest solution is to
> just always link them from make and remove any source level linkage.
Julian Waters has updated the pull request incrementally with five additional
commits since the last revision:
- Upd
On Mon, 17 Oct 2022 09:24:58 GMT, Magnus Ihse Bursie wrote:
> @TheShermanTanker Question: is this a Windows-specific thing, or are there
> pragma-loaded libraries for other compilers as well?
To my knowledge only Visual C++ has the ability to perform linking through
pragmas, the comment
o difference between
> specifying them from make and in a source file. The easiest solution is to
> just always link them from make and remove any source level linkage.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- use
o difference between
> specifying them from make and in a source file. The easiest solution is to
> just always link them from make and remove any source level linkage.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Update W
On Mon, 17 Oct 2022 14:31:46 GMT, Julian Waters wrote:
>> Some external libraries required by native code are linked via linker
>> comments embedded in pragmas. Searching for which libraries are linked can
>> then become frustrating and confusing since they may be included
o difference between
> specifying them from make and in a source file. The easiest solution is to
> just always link them from make and remove any source level linkage.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revis
Eclipse is a popular and very well-known IDE in the world of Java development,
utilized widely in many contexts, by beginners and experienced teams alike.
Although a relatively lightweight IDE, it features surprisingly powerful
indexing and code analysis capabilities, as well as useful tools,
On Tue, 25 Oct 2022 22:17:25 GMT, Erik Joelsson wrote:
> This looks like nice work.
>
> I'm curious how does this eclipse project figures out preprocessor settings
> like -D flags from the build to correctly setup the environment for the
> native code? I know this was a major deal when
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
On Wed, 26 Oct 2022 10:15:10 GMT, Thomas Stuefe wrote:
> Will this work with jtreg test sources too? At least on Intellij those
> require a brittle intellij plugin.
I didn't think of adding them to the indexing list if you're referring to the
code in the /test/ directory, but I can do that if
On Wed, 26 Oct 2022 09:59:13 GMT, Julian Waters wrote:
> I've heard some IDEs just run the build once and inspect the command lines,
> but our default log level won't show that.
I also forgot to mention that CDT does come with an integrated Build Output
Parser that can do just that, bu
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
s own
> Makefile within the ide subdirectory.
>
> Indexing capabilities utilizing the enhancement:
> src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG;>
> src="https://user-images.githubusercontent.com/32636402/
> Strip currently has its flags set by guessing based on the OS, it would be
> more appropriate to instead set them based on properly checking the strip
> binary instead of speculating what the correct flags are based on the
> compiler and OS.
Julian Waters has updated the
> Strip currently has its flags set by guessing based on the OS, it would be
> more appropriate to instead set them based on properly checking the strip
> binary instead of speculating what the correct flags are based on the
> compiler and OS.
Julian Waters has updated the
On Sat, 29 Oct 2022 07:12:40 GMT, Julian Waters wrote:
>> Strip currently has its flags set by guessing based on the OS, it would be
>> more appropriate to instead set them based on properly checking the strip
>> binary instead of speculating what the corre
> Strip currently has its flags set by guessing based on the OS, it would be
> more appropriate to instead set them based on properly checking the strip
> binary instead of speculating what the correct flags are based on the
> compiler and OS.
Julian Waters has updated the
[JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499) proposes to set the
-permissive- flag for the Microsoft Visual C++ compiler, to enforce strict
standards conformance during compilation, making native code behave more
strictly. While adding it to default builds is likely not practical
> Strip currently has its flags set by guessing based on the OS, it would be
> more appropriate to instead set them based on properly checking the strip
> binary instead of speculating what the correct flags are based on the
> compiler and OS.
Julian Waters has updated the
Strip currently has its flags set by guessing based on the OS, it would be more
appropriate to instead set them based on properly checking the strip binary
instead of speculating what the correct flags are based on the compiler and OS.
-
Commit messages:
- Merge branch
Hi all,
On Windows MakeBase contains a utility to extract Windows paths from Unix
style paths:
# FixPath
#
# On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) into
# "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return the path
# unchanged.
# This also converts a
On Sun, 23 Oct 2022 00:37:55 GMT, Phil Race wrote:
> > > Can you please refrain from integrating this while I investigate while
> > > this was originally moved?
> >
> >
> > sure.
>
> It was moved because it was designed for use by AWT and SOMEHOW during all
> the reshuffle for the modular
1 - 100 of 625 matches
Mail list logo
