date:20190301

This change bumps the Windows devkit version used for Oracle internal 
builds of the JDK to one based on Visual Studio 2017 15.9.6. In the 
generator script, I removed the conditionals around subsections to force 
the script to always generate the full kit. I've also made it a bit more 
automatic in finding internal version numbers/directories as well as 
added those version numbers in the devkit.info file. The old generator 
script for 2013 and 2015 are hardly relevant anymore so removing those.


Bug: https://bugs.openjdk.java.net/browse/JDK-8219988

Webrev: http://cr.openjdk.java.net/~erikj/8219988/webrev.01/index.html

/Erik

RFR: JDK-8219986: Change to Xcode 10.1 for building on Macosx at Oracle

This change bumps the Macosx devkit version used for Oracle internal 
builds of the JDK to one based on Xcode 10.1. I've also made the 
generator script a bit more automatic in detecting the versions. The old 
generator script for Xcode 6 is hardly relevant anymore so removing that.


Bug: https://bugs.openjdk.java.net/browse/JDK-8219986

Webrev: http://cr.openjdk.java.net/~erikj/8219986/webrev.01/index.html

/Erik

Re: RFR: JDK-8219971 Introduce SetupExecute in build system


Hello Magnus,

This looks really nice! The only thing I would wish for would be that 
you took some of the documentation you provided in this review mail and 
added it to Execute.gmk.


Concerning the future "chmod" post commands, I think those should just 
be add as something like " ; chmod $$@ " to COMMAND. The way the post 
command is defined now, it's a separate rule. A simple chmod really 
should be done in the same recipe as is creating the file.


/Erik

On 2019-03-01 05:24, Magnus Ihse Bursie wrote:
The most important operations performed by the build system is 
generalized into various Setup functionality, which forms the API 
on top of which the rest of the build system is erected.


However, we have a long tail with various small operations, calling a 
specific build tool, etc, that are done on a more ad-hoc basis. Over 
the years, a more and more refined set of "best practice" rules has 
emerged for such operations, but they tend to be implemented only for 
new operations, and not retrospectively updated on old code.


To make sure we always keep all such operations up to date with modern 
robustness solutions, I propose to create a new, more general, 
function, SetupExecute. Basically, this takes a command line to 
execute, and make sure this is done The Right Way.


In this patch, I'm introducing the SetupExecute function, and I've 
installed it for all locations that are currently using 
ExecuteWithLog. (Those were easy to find.) As the next step, 
operations that do not even use ExecuteWithLog (which is part of the 
"best practice" since some time ago, but was not from the start) 
should be located and converted, too.


I have verified using COMPARE_BUILD that the resulting output does not 
change. (The solaris_sparcv9 confirmation build is still running.)


The SetupExecute API works like this: You need to specify a COMMAND, 
the actual command line to execute. You are strongly recommended to 
provide a INFO with the text to display for LOG=info on what operation 
is performed. You can use DEPS to provide additional dependencies for 
your command to run. You can optionally include a PRE_COMMAND and a 
POST_COMMAND, intended for simple pre- and post-processing. The latter 
might be e.g. a mv from a temporary file to the final destination, the 
former e.g. a simple sed replacement on the input file. If the 
operations are unrelated to the main COMMAND, this is not a suitable 
solution.


If your command outputs a variety of files, or if it's really a single 
file but you don't really care about the output from the perspective, 
you can just supply a OUTPUT_DIR. You are supposed to make sure the 
command creates files in this directory (which will be created for you 
if it does not exist), but this can't be enforced by SetupExecute. 
Additional support files (like logs and markers) are created in this 
directory. If you want support files in a separate directory (e.g. if 
you're targeting an OUTPUT_DIR in the image directly), you can specify 
a SUPPORT_DIR. If your command outputs only a single file, you can get 
rid of the marker files (but not the log files) by specifying 
OUTPUT_FILE. Note that if you specify an OUTPUT_FILE, support log 
files will be placed in the same directory as the OUTPUT_FILE. If you 
do not want that, use SUPPORT_DIR as well.


After the call to SetupExecute, $1 will contain references to all 
generated files (that make knows about), and $1_TARGET will contain a 
reference to the final target (that is OUTPUT_FILE if it exists, or 
the $1_exec.marker file otherwise).


All the above keep functioning as expected even if PRE_COMMAND and 
POST_COMMAND are given. One special case worth noting is that if 
OUTPUT_FILE and POST_COMMAND is both given, the actual OUTPUT_FILE is 
considered to be a result of running the POST_COMMAND. (This will 
probably interact badly with a chmod as POST_COMMAND. I believe we 
still have a few such places, so this behavior might need to get 
revisited when I get around to converting those.)


While this might sound a bit convoluted, I find that it matches our 
actual usage very well. The guiding idea here, as in the other 
Setup functions, is to make the usage of the function as natural 
and simple as possible, even if at the expense of a slightly more 
complicated implementation.


Bug: https://bugs.openjdk.java.net/browse/JDK-8219971
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8219971-introduce-SetupExecute/webrev.01


/Magnus

Re: RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1


Build changes look good.

/Erik

On 2019-02-28 16:12, Philip Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8210782
Webrev: http://cr.openjdk.java.net/~prr/8210782/

This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 
which is currently the latest release of harfbuzz


harfbuzz is the 3rd party (external) C++ library used by OpenJDK for 
OpenType text layout.


In this large upgrade
- Many files were renamed following the pattern of 
"hb-foo-private.cc"  becoming "hb-foo.cc"

- Many new files were added
- A couple of files were deleted.

There are two additional changes on top of this
I needed to import a published but un-released fix to enable building 
with Oracle Studio 12.6 on Solaris
See 
https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978
I needed to reapply a fix made in JDK as JDK-8218965 that mirrors 
upstream to support building with the latest AIX compilers
See 
https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d
This doesn't show up as a "diff" in the JDK webrev which demonstrates 
that it is correctly re-applied as previously.


There are two JDK files changed :
(1)
- The makefile has been updated to disable several new warnings.
- To prevent harfbuzz from enabling warnings that were disabled - and 
avoid unknown pragma warnings we now define


-DHB_NO_PRAGMA_GCC_DIAGNOSTIC


See hb.hh for what harfbuzz is doing there, but without this -D option 
we cannot
disable warnings from the build since they are enabled in the code 
itself.


(2)
- A couple of harfbuzz APIs were deprecated so I needed to make code 
changes in hb-jdk-font.cc to use

the new API.

I have tested that this builds cleanly with all the current devkits 
(via the build servers) and that it also builds

with the in progress work to provide a gcc 8.2 devkit for Linux
I have also run all the related automated tests and performed some 
manual testing too.


-phil.

Re: RFR (trivial): 8219519: Remove linux_sparc.ad and linux_aarch64.ad

On 2019-03-01 15:39, Andrew Dinn wrote:

On 01/03/2019 14:25, Magnus Ihse Bursie wrote:

On 2019-02-27 03:25, Jie Fu wrote:

What do you mean by "optional"? The build code does this:

# Concatenate all ad source files into a single file, which will be fed to
# adlc.

...

AD_SRC_FILES := $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU).ad \
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH).ad \

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad

\
)))

so it will definitely pick up both those files and use it in creating
the concatenated ad file.

That's interesting because Pengfei Li claims he applied the patch and
successfully built OpenJDK on AArch64.

https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-February/006975.html

That being said, maybe this is not the correct behavior.

Well, something sounds fishy.

I see that the linux_sparc.ad file is essentially empty, so you can
probably remove that. The aarch64 file otoh seems to contain valid code.
I would not presume that you can just remove it!

He is ok to remove it as far as any contents are concerned. Indeed, I
told him this was ok in a review in the above thread after Pengfei
reported that OpenJDK built without the file being present.

As to the contents, the encoding defined in that file is completely
redundant (I don't really know how it got there as I don't believe it
was ever used)

Ok, it might very well be the case that the file is not needed since
it's contents is redundant. I can't say anything about that; that's the
domain of the adlc experts. However, it is incorrect to claim that the
build does not use file in question. But from the build PoV, it's
perfectly fine to remove it if it's not needed. But just not on the
grounds that it is not used by the build system!

/Magnus

regards,

Re: RFR (trivial): 8219519: Remove linux_sparc.ad and linux_aarch64.ad

2019-03-01 Thread Andrew Dinn

On 01/03/2019 14:25, Magnus Ihse Bursie wrote:
> On 2019-02-27 03:25, Jie Fu wrote:
>> It's a bit difficult for me to test this patch since I don't have a
>> sparc or arm machine.
>> I've analyzed the adlc processing logic in
>> make/hotspot/gensrc/GensrcAdlc.gmk finding that ad-files under
>> ./src/hotspot/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)
>> are optional.
> What do you mean by "optional"? The build code does this:
> 
>  
> ##
>   # Concatenate all ad source files into a single file, which will be fed to
>   # adlc.
> 
> ...
> 
>   AD_SRC_FILES := $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \
>   $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU).ad \
>   $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH).ad \
>  
> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad
> \
>     )))
> 
> so it will definitely pick up both those files and use it in creating
> the concatenated ad file.

That's interesting because Pengfei Li claims he applied the patch and
successfully built OpenJDK on AArch64.


https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-February/006975.html

Does the build system actually need those files to exist when it builds
the concatenated file?

> That being said, maybe this is not the correct behavior.

Well, something sounds fishy.

> I see that the linux_sparc.ad file is essentially empty, so you can
> probably remove that. The aarch64 file otoh seems to contain valid code.
> I would not presume that you can just remove it!
He is ok to remove it as far as any contents are concerned. Indeed, I
told him this was ok in a review in the above thread after Pengfei
reported that OpenJDK built without the file being present.

As to the contents, the encoding defined in that file is completely
redundant (I don't really know how it got there as I don't believe it
was ever used)

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: RFR: 8219920: dependency help output in configure-step : support zypper tool


On 2019-03-01 15:20, Baesken, Matthias wrote:


  * I suspect we should stop referring to using the system package
installer for the boot jdk, and instead
  * point to http://jdk.java.netfor the core platforms, and
https://adoptopenjdk.net/for the rest.

Hi Magnus ,  for OpenJDK11  (11u)  we might  mention  the packages .   
For the  jdk/jdk   it probably does not make much sense and the URLs 
are the way to go


Good point. JDK-8219788 is for jdk/jdk (13), feel free to open another 
bug for 11u.


/Magnus



.

Best regards, Matthias

*From:*Magnus Ihse Bursie 
*Sent:* Freitag, 1. März 2019 14:46
*To:* Baesken, Matthias ; 
'build-dev@openjdk.java.net' 
*Cc:* Simonis, Volker ; Zeller, Arno 

*Subject:* Re: RFR: 8219920: dependency help output in configure-step 
: support zypper tool


On 2019-03-01 09:48, Baesken, Matthias wrote:

Btw.  Speaking about  help.m4 help output ,   the mentioning of 
openjdk-8-jdk  in the various package-installer help outputs  seems to be 
outdated and  misleading to me :

   88 apt_help() {

   89   case $1 in

    . . .

   94 openjdk)

   95   PKGHANDLER_COMMAND="sudo apt-get install openjdk-8-jdk" ;;

   96 alsa)

   97   PKGHANDLER_COMMAND="sudo apt-get install libasound2-dev" ;;

I  think  we would need   jdk11 by  now (or soon jdk12, but  I am not sure 
about package  availability at the various distros for  12).


I agree. It's a bit of a problem, because the availability of the N-1 
JDK needed to compile is not regularly available through the normal 
distro package system, as other dependencies are.


I suspect we should stop referring to using the system package 
installer for the boot jdk, and instead point to http://jdk.java.net 
for the core platforms, and https://adoptopenjdk.net/ for the rest.


/Magnus

Re: RFR (trivial): 8219519: Remove linux_sparc.ad and linux_aarch64.ad

2019-03-01 Thread John Paul Adrian Glaubitz

Hello!

On 3/1/19 3:25 PM, Magnus Ihse Bursie wrote:
>> It's a bit difficult for me to test this patch since I don't have a sparc or 
>> arm machine.
Both SPARC and AArch64 machines running Linux can be accessed through the gcc
compile farm. Any open source developer can request an account for these
machines.

See:

> https://gcc.gnu.org/wiki/CompileFarm
> https://cfarm.tetaneutral.net/machines/list/

I'm admin for the sparc64 box running Linux in case someone needs any particular
package to be installed.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR (trivial): 8219519: Remove linux_sparc.ad and linux_aarch64.ad

On 2019-02-27 03:25, Jie Fu wrote:

Hi Tobias,

Thanks a lot for your review.

What do you mean by "optional"? The build code does this:

##
# Concatenate all ad source files into a single file, which will be
fed to

# adlc.

...

AD_SRC_FILES := $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU).ad \
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH).ad \
$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad
\

)))

so it will definitely pick up both those files and use it in creating
the concatenated ad file.

That being said, maybe this is not the correct behavior.

I see that the linux_sparc.ad file is essentially empty, so you can
probably remove that. The aarch64 file otoh seems to contain valid code.
I would not presume that you can just remove it!

/Magnus

Since both linux_sparc.ad and linux_aarch64.ad are useless for the
generation of C2, it would be better to remove them.

I'll try my best to test it.

By the way, I really appreciate If someone with sparc or aarch64
development environment could help to verify this change.

Thanks in advance.

Best regards,
Jie

On 2019/2/27 上午12:51, Tobias Hartmann wrote:

Hi Jie,

this looks good to me assuming that you have tested the change on
these platforms.

Best regards,
Tobias

On 21.02.19 10:35, Jie Fu wrote:

Hi all,

The following two source files are useless for the generation of C2
and should be removed.

1) ./src/hotspot/os_cpu/linux_sparc/linux_sparc.ad
2) ./src/hotspot/os_cpu/linux_aarch64/linux_aarch64.ad

Bug: https://bugs.openjdk.java.net/browse/JDK-8219519
Webrev: http://cr.openjdk.java.net/~jiefu/8219519/webrev.00/

Could you please review it?
Thanks a lot.

Best regards,
Jie

RE: RFR: 8219920: dependency help output in configure-step : support zypper tool

  *   I suspect we should stop referring to using the system package installer 
for the boot jdk, and instead
  *   point to http://jdk.java.net for the core platforms, and 
https://adoptopenjdk.net/ for the rest.

Hi Magnus ,  for OpenJDK11  (11u)  we might  mention  the packages .   For the  
jdk/jdk   it probably does not make much sense and the URLs are the way to go .

Best regards, Matthias


From: Magnus Ihse Bursie 
Sent: Freitag, 1. März 2019 14:46
To: Baesken, Matthias ; 'build-dev@openjdk.java.net' 

Cc: Simonis, Volker ; Zeller, Arno 
Subject: Re: RFR: 8219920: dependency help output in configure-step : support 
zypper tool

On 2019-03-01 09:48, Baesken, Matthias wrote:



Btw.  Speaking about  help.m4 help output ,   the mentioning of openjdk-8-jdk  
in the various package-installer help outputs  seems to be outdated and  
misleading to me :



  88 apt_help() {

  89   case $1 in



   . . .

  94 openjdk)

  95   PKGHANDLER_COMMAND="sudo apt-get install openjdk-8-jdk" ;;

  96 alsa)

  97   PKGHANDLER_COMMAND="sudo apt-get install libasound2-dev" ;;



I  think  we would need   jdk11 by  now (or soon jdk12, but  I am not sure 
about package  availability at the various distros for  12).

I agree. It's a bit of a problem, because the availability of the N-1 JDK 
needed to compile is not regularly available through the normal distro package 
system, as other dependencies are.

I suspect we should stop referring to using the system package installer for 
the boot jdk, and instead point to http://jdk.java.net for the core platforms, 
and https://adoptopenjdk.net/ for the rest.

/Magnus

RE: RFR: 8219920: dependency help output in configure-step : support zypper tool

Hi Magnus ,


  *   Have you verified that this actually works? E.g. by starting in a fresh 
SUSE installation, running configure,
  *   and then running the corresponding line and noticing that this helped 
configure get further on? Or did you just copy the yum/apt package names?

A bit of  both    .
I had  2 Linux  installs  with incomplete  packages  (e.g. cups and  X-related 
stuff was missing).
I  added the names  with the “missing …”  output   from  those 2  Linux  
installs  with incomplete  packages  .

However some packages we depend on  were already  available .

If you want I could  try to test on a  fresh   OpenSUSE .


Best regards,
 Matthias


From: Magnus Ihse Bursie 
Sent: Freitag, 1. März 2019 14:44
To: Baesken, Matthias ; 'build-dev@openjdk.java.net' 

Cc: Simonis, Volker ; Zeller, Arno 
Subject: Re: RFR: 8219920: dependency help output in configure-step : support 
zypper tool

On 2019-02-28 13:53, Baesken, Matthias wrote:

Hello, please review the following  change .



Currently  the  configure-step  outputs  help  for  a number of  packages + 
related installation calls  in case of missing dependencies  (like cups / alsa 
etc.) .

This help output step   covers a few  tools (like apt-get).





However the OpenSUSE / SLES tool zypper  is not supported .

This  change adds  output for  zypper .



Bug/webrev:



https://bugs.openjdk.java.net/browse/JDK-8219920



http://cr.openjdk.java.net/~mbaesken/webrevs/8219920.0/

Thank you for making the OpenJDK configure system even more self-helping!

This looks good to me.

Have you verified that this actually works? E.g. by starting in a fresh SUSE 
installation, running configure, and then running the corresponding line and 
noticing that this helped configure get further on? Or did you just copy the 
yum/apt package names?

/Magnus








Thanks, Matthias

Re: RFR: 8219920: dependency help output in configure-step : support zypper tool


On 2019-03-01 14:46, Magnus Ihse Bursie wrote:

On 2019-03-01 09:48, Baesken, Matthias wrote:
Btw.  Speaking about  help.m4 help output ,   the mentioning of 
openjdk-8-jdk  in the various package-installer help outputs  seems 
to be outdated and misleading to me :


   88 apt_help() {
   89   case $1 in

    . . .
   94 openjdk)
   95   PKGHANDLER_COMMAND="sudo apt-get install openjdk-8-jdk" ;;
   96 alsa)
   97   PKGHANDLER_COMMAND="sudo apt-get install libasound2-dev" ;;

I  think  we would need   jdk11 by  now (or soon jdk12, but  I am not 
sure about package  availability at the various distros for  12).


I agree. It's a bit of a problem, because the availability of the N-1 
JDK needed to compile is not regularly available through the normal 
distro package system, as other dependencies are.


I suspect we should stop referring to using the system package 
installer for the boot jdk, and instead point to http://jdk.java.net 
for the core platforms, and https://adoptopenjdk.net/ for the rest.


Actually Jesper opened this the other day: 
https://bugs.openjdk.java.net/browse/JDK-8219788


/Magnus



/Magnus



Best regards, Matthias



From: Baesken, Matthias
Sent: Donnerstag, 28. Februar 2019 13:53
To: 'build-dev@openjdk.java.net' 
Cc: Zeller, Arno ; Simonis, Volker 

Subject: RFR: 8219920: dependency help output in configure-step : 
support zypper tool


Hello, please review the following  change .

Currently  the  configure-step  outputs  help  for  a number of 
packages + related installation calls  in case of missing 
dependencies  (like cups / alsa etc.) .

This help output step   covers a few  tools (like apt-get).


However the OpenSUSE / SLES tool zypper  is not supported .
This  change adds  output for  zypper .

Bug/webrev:

https://bugs.openjdk.java.net/browse/JDK-8219920

http://cr.openjdk.java.net/~mbaesken/webrevs/8219920.0/


Thanks, Matthias

Re: RFR: 8219920: dependency help output in configure-step : support zypper tool


On 2019-03-01 09:48, Baesken, Matthias wrote:

Btw.  Speaking about  help.m4 help output ,   the mentioning of openjdk-8-jdk  
in the various package-installer help outputs  seems to be outdated and  
misleading to me :

   88 apt_help() {
   89   case $1 in

. . .
   94 openjdk)
   95   PKGHANDLER_COMMAND="sudo apt-get install openjdk-8-jdk" ;;
   96 alsa)
   97   PKGHANDLER_COMMAND="sudo apt-get install libasound2-dev" ;;

I  think  we would need   jdk11 by  now (or soon jdk12, but  I am not sure 
about package  availability at the various distros for  12).


I agree. It's a bit of a problem, because the availability of the N-1 
JDK needed to compile is not regularly available through the normal 
distro package system, as other dependencies are.


I suspect we should stop referring to using the system package installer 
for the boot jdk, and instead point to http://jdk.java.net for the core 
platforms, and https://adoptopenjdk.net/ for the rest.


/Magnus



Best regards, Matthias



From: Baesken, Matthias
Sent: Donnerstag, 28. Februar 2019 13:53
To: 'build-dev@openjdk.java.net' 
Cc: Zeller, Arno ; Simonis, Volker 
Subject: RFR: 8219920: dependency help output in configure-step : support 
zypper tool

Hello, please review the following  change .

Currently  the  configure-step  outputs  help  for  a number of  packages + 
related installation calls  in case of missing dependencies  (like cups / alsa 
etc.) .
This help output step   covers a few  tools (like apt-get).


However the OpenSUSE / SLES tool zypper  is not supported .
This  change adds  output for  zypper .

Bug/webrev:

https://bugs.openjdk.java.net/browse/JDK-8219920

http://cr.openjdk.java.net/~mbaesken/webrevs/8219920.0/


Thanks, Matthias

Re: RFR: 8219920: dependency help output in configure-step : support zypper tool


On 2019-02-28 13:53, Baesken, Matthias wrote:

Hello, please review the following  change .

Currently  the  configure-step  outputs  help  for  a number of  packages + 
related installation calls  in case of missing dependencies  (like cups / alsa 
etc.) .
This help output step   covers a few  tools (like apt-get).


However the OpenSUSE / SLES tool zypper  is not supported .
This  change adds  output for  zypper .

Bug/webrev:

https://bugs.openjdk.java.net/browse/JDK-8219920

http://cr.openjdk.java.net/~mbaesken/webrevs/8219920.0/


Thank you for making the OpenJDK configure system even more self-helping!

This looks good to me.

Have you verified that this actually works? E.g. by starting in a fresh 
SUSE installation, running configure, and then running the corresponding 
line and noticing that this helped configure get further on? Or did you 
just copy the yum/apt package names?


/Magnus



Thanks, Matthias

Re: RFR: JDK-8219906: Update test documentation with default test jobs settings


On 2019-02-28 09:13, Ao Qi wrote:

Hi,

Test jobs setting for sparc is different with x86 (JDK-8211727).
Besides, test jobs setting is based on memory size (JDK-8214003). The
test documentation fails to mention these and needs update.

Bug: https://bugs.openjdk.java.net/browse/JDK-8219906

Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.00/

Hi Ao,

The html file is generated from the markdown file. Please update 
testing.md instead, and then get yourself an automatically updated 
testing.html using "make update-build-docs". You will need pandoc for 
that to work, version 2.3.1 or newer is recommended (but not mandated).


/Magnus



Cheers,
Ao Qi

Re: How can I see where the sjavac_server is started?


On 2019-02-27 16:51, Erik Joelsson wrote:

Hello Andrew,

On 2019-02-26 12:09, Andrew Haley wrote:

I'm seeing a crash in the javac server while building openjdk.

We are seeing this too intermittently.

I want to run the exact same command that started the server running,
but even with LOG=debug I cannot find the command line that starts
it. The command seems not to be there at all.

So, how exactly does the javac server get started, and how do I find
the command line that started it?
The server is started lazily by the first javac invocation that needs 
it. There is a parameter given to javac that describes how it should 
be started, but to get the exact command line, you would have to 
instrument javac java source. You should be able to add additional 
parameters to that JVM, at least by editing spec.gmk, that could help 
you with diagnostics.

And, incidentally, given that I'f configured with --disable-sjavac,
why is the build running a javac server? Thanks.

The "smart javac" and the javac server are not one the same. The 
server was introduced in sjavac, but the server part was later ported 
over to javac proper (I think). So now we have two configure 
arguments, --enable-sjavac and --disable-javac-server. The latter is 
what you are looking for.


I think we should really get rid of sjavac since the relevant benefits 
are already present in the default build, with the javac server and 
the dependency plugin. The only possible benefit of sjavac today would 
be more fine grained incremental build support, but I doubt it works 
very well given that it's not being maintained.


Agree. I opened https://bugs.openjdk.java.net/browse/JDK-8219973.

/Magnus



/Erik

Re: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1


On 2019-03-01 01:12, Philip Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8210782
Webrev: http://cr.openjdk.java.net/~prr/8210782/

Looks good from a build PoV.

/Magnus



This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 
which is currently the latest release of harfbuzz


harfbuzz is the 3rd party (external) C++ library used by OpenJDK for 
OpenType text layout.


In this large upgrade
- Many files were renamed following the pattern of 
"hb-foo-private.cc"  becoming "hb-foo.cc"

- Many new files were added
- A couple of files were deleted.

There are two additional changes on top of this
I needed to import a published but un-released fix to enable building 
with Oracle Studio 12.6 on Solaris
See 
https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978
I needed to reapply a fix made in JDK as JDK-8218965 that mirrors 
upstream to support building with the latest AIX compilers
See 
https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d
This doesn't show up as a "diff" in the JDK webrev which demonstrates 
that it is correctly re-applied as previously.


There are two JDK files changed :
(1)
- The makefile has been updated to disable several new warnings.
- To prevent harfbuzz from enabling warnings that were disabled - and 
avoid unknown pragma warnings we now define


-DHB_NO_PRAGMA_GCC_DIAGNOSTIC


See hb.hh for what harfbuzz is doing there, but without this -D option 
we cannot
disable warnings from the build since they are enabled in the code 
itself.


(2)
- A couple of harfbuzz APIs were deprecated so I needed to make code 
changes in hb-jdk-font.cc to use

the new API.

I have tested that this builds cleanly with all the current devkits 
(via the build servers) and that it also builds

with the in progress work to provide a gcc 8.2 devkit for Linux
I have also run all the related automated tests and performed some 
manual testing too.


-phil.

RFR: JDK-8219971 Introduce SetupExecute in build system

The most important operations performed by the build system is 
generalized into various Setup functionality, which forms the API 
on top of which the rest of the build system is erected.


However, we have a long tail with various small operations, calling a 
specific build tool, etc, that are done on a more ad-hoc basis. Over the 
years, a more and more refined set of "best practice" rules has emerged 
for such operations, but they tend to be implemented only for new 
operations, and not retrospectively updated on old code.


To make sure we always keep all such operations up to date with modern 
robustness solutions, I propose to create a new, more general, function, 
SetupExecute. Basically, this takes a command line to execute, and make 
sure this is done The Right Way.


In this patch, I'm introducing the SetupExecute function, and I've 
installed it for all locations that are currently using ExecuteWithLog. 
(Those were easy to find.) As the next step, operations that do not even 
use ExecuteWithLog (which is part of the "best practice" since some time 
ago, but was not from the start) should be located and converted, too.


I have verified using COMPARE_BUILD that the resulting output does not 
change. (The solaris_sparcv9 confirmation build is still running.)


The SetupExecute API works like this: You need to specify a COMMAND, the 
actual command line to execute. You are strongly recommended to provide 
a INFO with the text to display for LOG=info on what operation is 
performed. You can use DEPS to provide additional dependencies for your 
command to run. You can optionally include a PRE_COMMAND and a 
POST_COMMAND, intended for simple pre- and post-processing. The latter 
might be e.g. a mv from a temporary file to the final destination, the 
former e.g. a simple sed replacement on the input file. If the 
operations are unrelated to the main COMMAND, this is not a suitable 
solution.


If your command outputs a variety of files, or if it's really a single 
file but you don't really care about the output from the perspective, 
you can just supply a OUTPUT_DIR. You are supposed to make sure the 
command creates files in this directory (which will be created for you 
if it does not exist), but this can't be enforced by SetupExecute. 
Additional support files (like logs and markers) are created in this 
directory. If you want support files in a separate directory (e.g. if 
you're targeting an OUTPUT_DIR in the image directly), you can specify a 
SUPPORT_DIR. If your command outputs only a single file, you can get rid 
of the marker files (but not the log files) by specifying OUTPUT_FILE. 
Note that if you specify an OUTPUT_FILE, support log files will be 
placed in the same directory as the OUTPUT_FILE. If you do not want 
that, use SUPPORT_DIR as well.


After the call to SetupExecute, $1 will contain references to all 
generated files (that make knows about), and $1_TARGET will contain a 
reference to the final target (that is OUTPUT_FILE if it exists, or the 
$1_exec.marker file otherwise).


All the above keep functioning as expected even if PRE_COMMAND and 
POST_COMMAND are given. One special case worth noting is that if 
OUTPUT_FILE and POST_COMMAND is both given, the actual OUTPUT_FILE is 
considered to be a result of running the POST_COMMAND. (This will 
probably interact badly with a chmod as POST_COMMAND. I believe we still 
have a few such places, so this behavior might need to get revisited 
when I get around to converting those.)


While this might sound a bit convoluted, I find that it matches our 
actual usage very well. The guiding idea here, as in the other 
Setup functions, is to make the usage of the function as natural 
and simple as possible, even if at the expense of a slightly more 
complicated implementation.


Bug: https://bugs.openjdk.java.net/browse/JDK-8219971
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8219971-introduce-SetupExecute/webrev.01


/Magnus

RE: RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1

Hi Phil , are you aware of any  minimum compiler version requirements  coming  
with  HarfBuzz   2.3.1   ?

Best regards, Matthias


> From: Philip Race 
> To: 2d-dev <2d-...@openjdk.java.net>, build-dev
>   
> Subject: RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1
> Message-ID: <5c787909.4090...@oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210782
> Webrev: http://cr.openjdk.java.net/~prr/8210782/
> 
> This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which
> is currently the latest release of harfbuzz
> 
> harfbuzz is the 3rd party (external) C++ library used by OpenJDK for
> OpenType text layout.
> 
> In this large upgrade
> - Many files were renamed following the pattern of "hb-foo-private.cc"
> becoming "hb-foo.cc"
> - Many new files were added
> - A couple of files were deleted.
> 
> There are two additional changes on top of this
> I needed to import a published but un-released fix to enable building
> with Oracle Studio 12.6 on Solaris
> See
> https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094c
> c7abc10ed231978
> I needed to reapply a fix made in JDK as JDK-8218965 that mirrors
> upstream to support building with the latest AIX compilers
> See
> https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef9
> 05b896e42d39f1d
> This doesn't show up as a "diff" in the JDK webrev which demonstrates
> that it is correctly re-applied as previously.
> 
> There are two JDK files changed :
> (1)
> - The makefile has been updated to disable several new warnings.
> - To prevent harfbuzz from enabling warnings that were disabled - and
> avoid unknown pragma warnings we now define
> 
> -DHB_NO_PRAGMA_GCC_DIAGNOSTIC
> 
> 
> See hb.hh for what harfbuzz is doing there, but without this -D option
> we cannot
> disable warnings from the build since they are enabled in the code itself.
> 
> (2)
> - A couple of harfbuzz APIs were deprecated so I needed to make code
> changes in hb-jdk-font.cc to use
> the new API.
> 
> I have tested that this builds cleanly with all the current devkits (via
> the build servers) and that it also builds
> with the in progress work to provide a gcc 8.2 devkit for Linux
> I have also run all the related automated tests and performed some
> manual testing too.
> 
> -phil.
>

RE: RFR: 8219920: dependency help output in configure-step : support zypper tool