Hi,
I see the same on my windows build. I verified that 8.3 filenames are enabled.
I took a little closer look. In my PATH env in Cygwin I have:
...:/cygdrive/c/Program Files/Git/cmd:...
The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in basic_tools.m4.
UTIL_LOOKUP_PROGS, defined in
Hi,
that's because the PR is a based on a pre-loom version of master.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of Philip Race
> Sent: Montag, 23. Mai 2022 17:14
> To: Aleksey Shipilev ; Ioi Lam ;
> build-dev@openjdk.java.net
> Subject: Re: pre-submit
of the environment I think that also the ubuntu container that
is used is updated from time to time for certain patches and we usually don't
recognize it.
Best regards
Christoph
> -Original Message-
> From: Magnus Ihse Bursie
> Sent: Mittwoch, 13. April 2022 12:58
> To: Lange
Hi Andrew,
> > > One dummy question:
> > > Why do we need to specify the real package name here?
> > > If we install gcc-10, I think apt system will pick up the latest gcc-10
> > > for us.
> >
> > IIRC the intent is to keep control over the gcc version and not
> > randomly update whenever the
Hi Andrew, all,
> On 09:19 Fri 14 Jan , Baesken, Matthias wrote:
> > For one of the next jdk11 updates, an update to a more recent harfbuzz
> version is planned.
> >
> > However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they
> are built with option -std=c++11).
> > So please
Hi Martin,
looks good. I also verified that it removes the warning messages in the build.
Approved.
Best regards
Christoph
From: Doerr, Martin
Sent: Donnerstag, 14. Januar 2021 17:50
To: jdk-updates-...@openjdk.java.net; build-dev@openjdk.java.net
Cc: Lindenmaier, Goetz ; Langer, Christoph
Thanks for the review, Alan.
I'll push it then.
Best regards
Christoph
> -Original Message-
> From: Alan Bateman
> Sent: Mittwoch, 1. April 2020 16:46
> To: Langer, Christoph ; Mandy Chung
> ; core-libs-...@openjdk.java.net
> Cc: build-dev
> Subject: Re: RF
://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ?
Thanks
Christoph
From: Mandy Chung
Sent: Dienstag, 31. März 2020 19:34
To: Langer, Christoph ; core-libs-...@openjdk.java.net
Cc: build-dev
Subject: Re: RFR (S): 8241947: Minor comment fixes for system property handling
On 3/31/20 7:56 AM, Langer, Christoph
Hi Magnus,
> From a build perspective this looks fine.
Thanks for the review.
> But it seems you are changing the interface for java.lang.System. Don't
> you need a CSR for that? Or is your claim that the interface was indeed
> changed by JDK-8197927, and it is a bug that the documentation was
Hi,
please review a small fix that updates two comments.
The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks
about handling of a property "vm.vendor" in VersionProps.java.template.
However, there is no property "vm.vendor", it must rather be "java.vendor". I
stumbled
).
Cheers
Christoph
> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 12. März 2020 18:12
> To: Langer, Christoph ; jdk-updates-dev updates-...@openjdk.java.net>
> Cc: build-dev
> Subject: RE: [11u]: RFR 8235686: Add more custom hooks in Bundles.
Hi,
I've regenerated this webrev as well:
http://cr.openjdk.java.net/~clanger/webrevs/8232748.11u/ (with JDK-8223678 and
JDK-8232572 applied)
Patch content looks identical to the one already reviewed.
I'd volunteer to push this in order with the other patches.
Cheers
Christoph
>
Hi,
I regenerated the webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u.1/
Still looks pretty much the same as before. Will push to jdk11u-dev after
JDK-8223678.
Cheers
Christoph
From: Langer, Christoph
Sent: Montag, 9. März 2020 14:57
To: jdk-updates-...@openjdk.java.net
Cc
Thanks, Severin. I pushed it to jdk11u-dev now.
Cheers
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Mittwoch, 11. März 2020 15:53
> To: Langer, Christoph ; Volker Simonis
> ; Andrew Hughes ;
> jdk-updates-...@openjdk.java.net
> Cc: build-dev
>
Hi,
please help to review this Oracle-11.0.7 parity backport for the build system.
Bug: https://bugs.openjdk.java.net/browse/JDK-8235686
Original Change: https://hg.openjdk.java.net/jdk/jdk14/rev/91a3f092682f
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u/
The patch needed some
Hi Severin,
> > So you think we should have the hunk in
> > make/hotspot/lib/CompileJvm.gmk or leave it out?
>
> Leave it out, please. If anything it should be part of a future
> JDK-8220383 backport.
OK, I guess you're right. Here is the new webrev:
Hi Severin,
thanks for the review.
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189861
> > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e297c7bb6469
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u/
>
> I've compared it to the original change and it looks
Hi Volker,
> > Out of interest, is the AssertEquals macro something worth backporting
> > at some point? Generally, I find its worthwhile if people are going to
> > be doing the same replacement in multiple backports.
> >
>
> I actually wanted to answer something like "..lets wait until we get
>
Hi,
for the backports of "JDK-8223678 Add Visual Studio Code workspace generation
support (for native code)" and "JDK-8232748 Build static versions of certain
JDK libraries" it seems useful to first backport the refactoring of CacheFind.
Furthermore it can improve performance in the Windows
Thanks, Thomas.
From: Thomas Stüfe
Sent: Montag, 9. März 2020 17:24
To: Langer, Christoph
Cc: jdk-updates-...@openjdk.java.net; build-dev
Subject: Re: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk
LGTM.
..Thomas
On Mon, Mar 9, 2020 at 2:57 PM Langer, Christoph
Thanks Erik, for this clarification.
We won't backport it then.
Cheers
Christoph
-Original Message-
From: Erik Joelsson
Sent: Montag, 9. März 2020 16:44
To: Langer, Christoph ;
jdk-updates-...@openjdk.java.net
Cc: build-dev
Subject: Re: 11u RFR: 8232569: Use test image from
Hi,
Please help reviewing this Oracle parity backport
Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/
I had to make several adaptions because some
Hi,
please review this Oracle parity backport.
Bug: https://bugs.openjdk.java.net/browse/JDK-8232572
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u/
I had to manually bring some hunks to the right position in
Hi,
sorry for the delay. I didn't have so much time in the last two weeks but now
I'm back full steam, tackling jdk11u build system again
So this one is really trivial, and should be done in any case. I've approved it.
Cheers
Christoph
-Original Message-
From: jdk-updates-dev On
Hi,
Thanks, Volker for backporting this to JDK11 and thanks Andrew for reviewing it.
> On 30/12/2019 20:18, Volker Simonis wrote:
> > Hi,
> > I'd like to downport the support for Visual Studio Code project
> > creation to 11u. I think we will have to support 11u for quite some
> > years and it
. Japanese.
Cheers
Christoph
> -Original Message-
> From: Ichiroh Takiguchi
> Sent: Donnerstag, 20. Februar 2020 10:57
> To: Sergey Bylokhov
> Cc: Langer, Christoph ; Philip Race
> ; awt-...@openjdk.java.net; build-
> d...@openjdk.java.net; ppc-aix-port-...@openjdk.j
nal Message-
> From: David Holmes
> Sent: Donnerstag, 20. Februar 2020 09:28
> To: Langer, Christoph ; 'build-
> d...@openjdk.java.net' ; 'hotspot-
> d...@openjdk.java.net' ; Erik Joelsson
> ; Magnus Ihse Bursie
>
> Subject: Re: Mach5 test failure when testing JD
...@oracle.com
Sent: Mittwoch, 19. Februar 2020 21:16
To: Langer, Christoph
Subject: [Mach5] mach5-one-clanger-JDK-8237192-20200219-1906-8861422: FAILED,
Failed tests: 1
Job: mach5-one-clanger-JDK-8237192-20200219-1906-8861422
BuildId: 2020-02-19-1905201.christoph.langer.source
Failed tests: showing 1
Hi Erik,
thanks for the review. Seems like it’s looking good now in our CI. I’ll run it
through jdk-submit before pushing.
Best regards
Christoph
From: Erik Joelsson
Sent: Dienstag, 18. Februar 2020 18:09
To: Langer, Christoph ; Magnus Ihse Bursie
; 'build-dev@openjdk.java.net'
Cc
files in
images/jdk/bin on non Windows platforms.
http://cr.openjdk.java.net/~clanger/webrevs/8237192.2/
Cheers
Christoph
From: Langer, Christoph
Sent: Montag, 17. Februar 2020 10:17
To: Erik Joelsson ; Magnus Ihse Bursie
; 'build-dev@openjdk.java.net'
Cc: 'hotspot-...@openjdk.java.net
/ modules_libs_full_debug_info etc.
Here's the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237192.1/
Best regards
Christoph
From: Erik Joelsson
Sent: Mittwoch, 12. Februar 2020 23:17
To: Langer, Christoph ; Magnus Ihse Bursie
; 'build-dev@openjdk.java.net'
Cc: 'hotspot
Hi Matthias,
Backport looks good to me, too. But please move the new section before
TOOLCHAIN_CFLAGS_JDK_CONLY in make/autoconf/flags-cflags.m4, as suggested by
Andrew. No need for new webrev.
Cheers
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Andrew John Hughes
>
Hi Alan,
> On 12/02/2020 22:16, Erik Joelsson wrote:
> > Hello Christoph,
> >
> > This patch certainly looks better to me, though I agree it's a bit
> > hackish to have to filter and rename the stripped.pdb files twice,
> > once for jmods and again for bundles. I think I'm ok with it for now
> >
Great. I'll push it tomorrow.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Donnerstag, 13. Februar 2020 18:18
> To: René Schünemann ; Langer, Christoph
>
> Cc: build-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8238534
>
> Looks good.
>
Hi René,
to me your latest webrev looks quite good. You could pull the PRODUCT_TARGETS
+= $(BUILD_JDK_BUNDLE) and LEGACY_TARGETS += $(BUILD_JRE_BUNDLE) out of the
if/else blocks as they are common to both. But I also see a value in keeping
them duplicated where they are, so they immediately
me know what you think.
Thanks & Best regards
Christoph
From: Magnus Ihse Bursie
Sent: Freitag, 7. Februar 2020 14:09
To: Baesken, Matthias ; Erik Joelsson
; Langer, Christoph ; David
Holmes ; 'build-dev@openjdk.java.net'
; 'hotspot-...@openjdk.java.net'
Subject: Re: RFR: 8237192: Gene
Hi,
let me chime in to this discussion at this point. So, first of all, Matthias,
thanks for your work so far.
Erik, I fully understand your points and I agree that it's probably a good idea
to refactor this whole process of creating these different types of bundles.
Our idea is to provide
Hi Erik,
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.02/
>
> On 2020-02-05 02:17, Langer, Christoph wrote:
> > Hi,
> >
> > we've tested the patch and all reported failure scenarios we're aware of
> are
//
JDK_IMAGE_DIR=$PWD/images/jdk-bundle/jdk-15.jdk/Contents/Home
(e.g. use relative paths inside the build directory)
Thanks
Christoph
> -Original Message-
> From: Magnus Ihse Bursie
> Sent: Mittwoch, 5. Februar 2020 10:54
> To: Erik Joelsson ; core-libs-dev
Hi Erik,
> Does anyone have an opinion on this?
Yep, first of all, thanks for doing this work. Sorry for not replying earlier
but FOSDEM/openjdkcw has kept us a bit busy. We're in the process of testing
your change in the reported cases where behavior is broken and shall supply you
with
. Januar 2020 09:09
To: Langer, Christoph ; build-dev
Subject: Re: RFR: 8236488: Support for configure option
--with-native-debug-symbols=internal is impossible on Windows
Hello Christoph,
I think the change makes sense and follows the established behavior on AIX for
invalid settings
Thanks for the review, Martin.
> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 23. Dezember 2019 15:12
> To: Langer, Christoph ; jdk-updates-dev updates-...@openjdk.java.net>
> Cc: build-dev
> Subject: RE: [11u] RFR: 8232167: Visual Studio
Thanks for the review, Martin.
> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 23. Dezember 2019 16:02
> To: Langer, Christoph ; jdk-updates-dev updates-...@openjdk.java.net>
> Cc: build-dev
> Subject: RE: [11u] RFR: 8236500: Windows ucrt.dl
Hi,
please review a backport of a carveout of JDK-8215445: "Enable building for
Windows in WSL" [0]. When building 11u after I've reinstalled Visual Studio and
the Windows Devkit to non-default folder locations, I ran into the issue that
ucrt.dll would not be correctly resolved, since it sits
Hi,
please review this simple backport of a simple build system fix which
unfortunately did not apply cleanly. It's just context changes that needed to
be resolved. I ran into this with jdk11u after I reinstalled my Visual Studio
to a non-default folder and used configure option
Hi,
please review the following change as a follow up to an earlier discussion
here: http://mail.openjdk.java.net/pipermail/build-dev/2019-December/026408.html
On Windows it's not possible to support configure option
"--with-native-debug-symbols=internal" in a way that one would expect. E.g.
Hi Mikael,
thank you for fixing this.
Cheers
Christoph
From: Mikael Vidstedt
Sent: Mittwoch, 11. Dezember 2019 20:31
To: Langer, Christoph
Cc: build-dev
Subject: Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and
SPARC Ports
Christoph,
Thanks for reporting! I filed
Hi Mikael (or build folks),
after 8234370 was submitted, I recognize the following output for configure:
stdin:85: warning: AC_REQUIRE: `PLATFORM_EXTRACT_TARGET_AND_BUILD' was expanded
before it was required
stdin:85:
Hi René,
LGTM, too.
I'll sponsor it for you.
Cheers
Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 10. Dezember 2019 15:35
> To: René Schünemann ; Langer, Christoph
>
> Cc: build-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8235585: Ena
Hi René,
thanks for doing this.
I agree to Erik's findings, these should be addressed. Other than that, I have
no further points.
It would be good, if this little enhancement can be pushed before Thursday to
make it into JDK14 without special approval.
Best regards
Christoph
>
nal Message-
> From: Erik Joelsson
> Sent: Mittwoch, 4. Dezember 2019 15:46
> To: Bob Vandette
> Cc: Langer, Christoph ; build-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net; hotspot-dev
> developers
> Subject: Re: native debug symbols support on Windows
>
Hi,
I'm currently looking into native debug symbols support for Windows.
The OpenJDK build system supports these two configure flags
--with-native-debug-symbols= (among a few other options
which I don't want to discuss here).
So, the name implies that for "internal", debug symbols should be
Sent: Mittwoch, 30. Oktober 2019 15:38
To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net'
Cc: Langer, Christoph ; Doerr, Martin
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when
compiling with xlc16/legacy-xlc
Hello, please review the following small AIX
Hi Severin,
backport looks good. Thanks for doing it.
Cheers
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 29. Oktober 2019 19:19
> To: jdk-updates-dev
> Cc: build-dev
> Subject: [11u] RFR: 8214311: dtrace gensrc has missing
Hi Severin,
good catch, thank you.
Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 10. Oktober 2019 15:15
> To: Langer, Christoph ; jdk-
Hi,
please help reviewing this backport of a build infrastructure change to jdk11u.
One reason for doing this is parity with Oracle's 11.0.6 but the patch also
contains some test improvements which will help stabilizing 11u testing. This
mainly means increasing some test timeouts for a few
David Holmes
> Sent: Mittwoch, 18. September 2019 01:13
> To: Erik Joelsson ; Magnus Ihse Bursie
> ; Langer, Christoph
> ; OpenJDK Serviceability d...@openjdk.java.net>; build-dev
> Subject: Re: RFR: 8230857: Avoid reflection in
> sun.tools.common.ProcessHelper
>
> Hi Eri
Done.
http://hg.openjdk.java.net/jdk/jdk/rev/593005ac5a0a
> -Original Message-
> From: Simon Tooke
> Sent: Donnerstag, 12. September 2019 22:25
> To: Langer, Christoph ; Erik Joelsson
> ; David Holmes ;
> build-dev
> Subject: Re: JDK 14 RFR:
Hi,
I've also played with this already and support Simon's patch.
Simon, shall I sponsor it for you?
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of Erik
> Joelsson
> Sent: Donnerstag, 12. September 2019 17:10
> To: David Holmes ; Simon Tooke
> ; build-dev
Hi Matthias,
> May I have a second reviewer please?
Sure, looks good to me - this seems the right way to go forward
Best regards
Christoph
Hi Matthias,
I would second that.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Dienstag, 16. Juli 2019 16:40
> To: 'build-dev@openjdk.java.net'
> Subject: [CAUTION] build.log: Output from failing command(s) repeated
> here - do
Hi,
with today’s push for „8227578: Wrong JRE targets in Images.gmk after
JDK-8219971” I didn’t catch all issues with the JRE target and especially not
the one that’s causing our build errors. But now I’ve got it
Please review this one line fix.
Bug:
Hi,
please review this little bugfix in Images.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227578
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227578.0/
I guess it's only relevant when building "legacy-bundles" or something that
builds jre-images. However in that case we
Hi Severin,
now it's good from my end. Finally
Thanks
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Mittwoch, 10. Juli 2019 11:25
> To: Langer, Christoph
> Cc: build-dev ; Andrew John Hughes
> ; jdk8u-dev
> Subject: Re: [8u] RFR: 8210761: libj
Hi Severin,
You made a little mistake. It must be "-xO4" instead of "-x04" in the Solaris
build file (It's the letter O instead of the number 0)
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Dienstag, 9. Juli 2019 12:09
++ compiler, but libjsig.o is compiled
with the C compiler. And the C compiler does not like -g0 but needs just -g.
Best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 4. Juli 2019 14:21
> To: Severin Gehwolf ; Andrew John Hughes
> ; jdk8u-d
Hi Matthias,
looks good!
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Montag, 8. Juli 2019 14:00
> To: Thomas Stüfe
> Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
> Subject: [CAUTION] 8227389: Remove
Hi Severin,
as we have the Solaris infrastructure in-house, let me try to produce something
for Solaris. I'll get back to you soon...
Cheers
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 4. Juli 2019 14:18
> To: Langer, Christoph ; Andrew
work for Oracle Studio (12 u1) when compiling and
linking in one go. A fix would be to split compilation and linking of the lib
into 2 steps, I guess.
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 4. Juli 2019 11:39
> To: Lange
> Here you go:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210761/jdk8/02/webrev/
>
> I cannot really test on bsd, solaris or aix, though :( Appreciate any
> testers for those platforms.
I pulled the patch into our test environment. It will be run for AIX and
solaris there. Will let
> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
> the 8u equivalent not also be applied to the solaris, bsd and aix
> subdirectories as well for consistency?
+1 We can test this for AIX.
Cheers
Christoph
Hi Severin,
I think this is good.
Best regards
Christoph
> -Original Message-
> From: jdk8u-dev On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 25. Juni 2019 11:04
> To: jdk8u-dev
> Cc: build-dev
> Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
>
> Hi,
>
Hi Max,
this looks all good to me now :)
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Weijun Wang
> Sent: Freitag, 31. Mai 2019 05:01
> To: Erik Joelsson
> Cc: security-...@openjdk.java.net; build-dev d...@openjdk.java.net>
> Subject: Re: RFR 8193255:
Hi Max,
first of all, thanks for doing this enhancement. That'll really help in the
future when downstream vendors merge in additional certificates (or remove
some) like we do with SapMachine. Currently we have to resolve manually
everytime cacerts is modified.
As for the dependencies: if you
Ping: Can I please get a review for this?
From: Langer, Christoph
Sent: Dienstag, 30. April 2019 11:26
To: jdk-updates-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; build-dev@openjdk.java.net; Baesken,
Matthias
Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3
Hi,
please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the
latest 2.3.1.
This has been backported to 11.0.4-oracle already. I took the large change down
to 11u-dev. It applies quite nicely, apart from a little issue in
make/lib/Awt2dLibraries.gmk:
--- Awt2dLibraries.gmk
Hi Gary,
fair point.
cc-ing build-dev. Can you please check this change. Maybe you can comment on
the background why JDKLIB_LIBS does not include -ljava, too?
Thanks
Christoph
> -Original Message-
> From: Gary Adams
> Sent: Freitag, 26. April 2019 14:15
> To: Langer, Chr
Thanks Volker. I see you are member of the build group… so I had a good feeling
when I pushed this
http://hg.openjdk.java.net/jdk/jdk/rev/3b2101f56cdd
From: Volker Simonis
Sent: Mittwoch, 17. April 2019 07:54
To: Langer, Christoph
Cc: build-dev@openjdk.java.net
Subject: Re: RFR(XS
Hi,
please review this little revert of a token that accidentally sneaked in when I
pushed JDK-8222522 (Add configure options for Mac Bundle creation) yesterday. I
don't know how that happened but fortunately it didn't break the build...
diff -r 15f2aae40bc8 -r ae1be0d04777
Thanks Erik. I pushed it.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 16. April 2019 15:22
> To: Langer, Christoph ; build-
> d...@openjdk.java.net
> Subject: Re: RFR(S): 8222522: Add configure options for Mac Bundle creation
>
>
Hi,
please review a small build enhancement.
I'd like to add configure options for the Mac Bundle name/id:
--with-macosx-bundle-name-base and --with-macosx-bundle-id-base.
Bug: https://bugs.openjdk.java.net/browse/JDK-8222522
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222522.0/
Hi Man,
the change looks good to me, thanks for doing this cleanup.
As for reviewers: I thought it depends whether the author of a change is a
Reviewer himself. Then only one Reviewer needs to review the change. But I
might be wrong here. So, let's wait for a review from the build group and
And done.
> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 10. April 2019 17:13
> To: Erik Joelsson ; Schmelter, Ralf
> ; build-dev@openjdk.java.net
> Subject: RE: RFR (S) Windows incremental build is broken with JDK-8217728
>
>
Ok, about to do it now...
> -Original Message-
> From: Erik Joelsson
> Sent: Mittwoch, 10. April 2019 17:03
> To: Langer, Christoph ; Schmelter, Ralf
> ; build-dev@openjdk.java.net
> Subject: Re: RFR (S) Windows incremental build is broken with JDK-8217728
>
> Th
Hi Ralf,
looks good. I'll sponsor it for you.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Schmelter, Ralf
> Sent: Mittwoch, 10. April 2019 14:23
> To: build-dev@openjdk.java.net
> Subject: [CAUTION] RFR (S) Windows incremental build is broken with JDK-
Thanks, Erik.
I already checked and will check carefully once again before pushing.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 9. April 2019 15:22
> To: Langer, Christoph ; build-
> d...@openjdk.java.net; hotspot-...@openjdk.java.net
Hi,
during work on JDK-8221880 I spotted some opportunity for cleanup in Windows
resource files and their handling in the build.
The naming of variables used for customizing resource properties in the build
system should be aligned between hotspot and JDK. This should be carefully
reviewed by
Hi Erik,
> > Good. Then we are back at my latest webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8221880.1/
>
> Ah, right, this change does not remove JDK_RC_PLATFORM_NAME from
> version-numbers, but it does remove it from spec.gmk.in. Could you leave
> it in spec.gmk.in? Then you can
Hello Erik,
> >> In OpenJDK builds, the current strings evaluate to "OpenJDK Platform"
> >> and for Oracle builds "Java(TM) Platform SE". It makes me curious as to
> >> what you need to modify the string to?
> > We want to print "SapMachine" there, see this commit:
> >
>
version-numbers at all and hard
> code the value "Platform" in make/autoconf/jdk-version.m4?
> >
> > /Christoph
> >
> >
> >> -Original Message-
> >> From: Langer, Christoph
> >> Sent: Mittwoch, 3. April 2019 16:25
> >> T
age-
> > From: Erik Joelsson
> > Sent: Mittwoch, 3. April 2019 16:18
> > To: Langer, Christoph ; build-
> > d...@openjdk.java.net
> > Subject: Re: RFR (S): 8221880: Better customization for Windows RC
> > properties FileDescription and ProductName
> >
&
Hi,
I'd like to backport the resurrection of the legacy JRE bundle target to jdk11
updates because it would help a lot in our build infrastructure. Maybe other
downstream vendors can take profit of this, too.
The patch doesn't apply cleanly, so I had to resolve a bit. Please review my
Hi,
In our downstream build, I'd like to be able to set/customize the value for the
Windows RC properties "ProductName" and "FileDescription" via the
version-numbers file. These values manifest in Windows executable properties.
During the build ProductName gets set to "OpenJDK Platform 13" and
. März 2019 15:54
To: Zeller, Arno ; Langer, Christoph
; build-dev@openjdk.java.net
Cc: Schuenemann, Rene
Subject: Re: RFR: 8221610: Resurrect (legacy) JRE bundle target
Hello,
On 2019-03-28 04:47, Zeller, Arno wrote:
Hi Christoph,
thanks for the patch. Just one small suggestion – I think you
Hi Alan
> I'm curious who these "stakeholders" are and what they use these JRE
> bundle for? As you know, moving to a modular platform has blurred the
> historical distinction between what we knew as the JRE and JDK in the
> past. Are they concerned about disk space?
I think the requirement
Looks good to me now
> -Original Message-
> From: Andrew John Hughes
> Sent: Freitag, 29. März 2019 07:18
> To: Langer, Christoph ; Severin Gehwolf
> ; 'jdk8u-...@openjdk.java.net' d...@openjdk.java.net>; build-dev@openjdk.java.net
> Subject: Re: [RFR] [8u]
Hi,
> > Revised HotSpot webrev:
> >
> > https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>
> +++ new/src/share/vm/runtime/vm_version.cpp 2019-03-28
> 03:52:51.384737947 +
> @@ -140,7 +140,7 @@
>
> const char* Abstract_VM_Version::vm_vendor() {
> #ifdef VENDOR
> - return
Hi Andrew,
thanks for doing this backport. I agree, Severin's finding needs to be added to
hotspot's Unix/Posix vm.make files.
Also, the additional printing of those variables in the Unixish buildtree.make
files should be added to windows' make/windows/build.make in target
Hi Matthias,
first of all: The change looks good to me, +1.
I assume you have run it through our build/test infrastructure and see no
regressions...
As for the process:
In your case, you want to backport a change and the original patch does not
apply cleanly. For that scenario, you don't have
Hi,
the Mac experts will probably find my question to be silly and start laughing…
but nevertheless, I’m asking it here
I was looking into building OpenJDK 8 today on my developer Mac, which runs
Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was
trying to install
1 - 100 of 134 matches
Mail list logo
