[11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects

2019-12-30 Thread Volker Simonis
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 makes sense to have as good as possible tool support in
11u as well.

This mail is especially intended to get a review from the build team
that the few changes to the patches are OK:

https://bugs.openjdk.java.net/browse/JDK-8210459
http://cr.openjdk.java.net/~simonis/webrevs/2019/8210459/

https://bugs.openjdk.java.net/browse/JDK-8218807
http://cr.openjdk.java.net/~simonis/webrevs/2019/8218807/

https://bugs.openjdk.java.net/browse/JDK-8223678
http://cr.openjdk.java.net/~simonis/webrevs/2019/8223678/

The downport consists of three changes which are additive (i.e. later
changes depend on earlier ones). That's why I decided to post just one
RFR, because looking at a single change makes no sense without the
corresponding context. The changes mostly apply cleanly except for
very few places where we need manual adjustments because of changed
context.

These changes only touch make files and actually only add new features
to the make system, so the normal build results shouldn't be affected.
I've tested that the build still works on Linux and Windows and "make
test-make" succeeds.

Following some details on the three changes:

8210459: Add support for generating compile_commands.json

The initial change which creates the compile_commands.json file (i.e.
"make compile_commands"). This file can be used for many tools (e.g.
CLion IDE, clangd, etc..)
Applies cleanly except for the following hunk, which has a different context:

ORIGINAL

CFLAGS_solaris := -KPIC, \
 CFLAGS_macosx := -fPIC, \
 DISABLED_WARNINGS_clang := format-nonliteral, \
-LDFLAGS := $(UNPACKEXE_ZIPOBJS) \
-$(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
+LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \

JDK11u
==
CFLAGS_linux := -fPIC, \
 CFLAGS_solaris := -KPIC, \
 CFLAGS_macosx := -fPIC, \
-LDFLAGS := $(UNPACKEXE_ZIPOBJS) \
-$(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
+LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \

8218807: Compilation database (compile_commands.json) may contain obsolete items

This is a simple fix for 8210459 and applies cleanly

8223678: Add Visual Studio Code workspace generation support (for native code)

This change actually creates the VS Code project files (i.e. "make
vscode-project-ccls"). See
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/ide.html for more
details.

Applies cleanly except the following two hunks. The first one had to
be moved back from "make/common/Utils.gmk" to
"make/common/MakeBase.gmk" where it still applies cleanly, because the
"RelativePath" macro is still in "MakeBase.gmk" in  jdk11u.

ORIGINAL

diff -r a82a367b2d8c -r 2ae056696b15 make/common/Utils.gmk
--- a/make/common/Utils.gmkMon Jun 03 17:14:23 2019 -0700
+++ b/make/common/Utils.gmkMon Jun 03 10:28:03 2019 +0200
@@ -122,7 +122,8 @@
 # $2 - Directory to compute the relative path from
 RelativePath = \
 $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \
-$(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip
$1)_prefix)/%, %, $2))) \
+$(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip
$1)_prefix)%, %, $2))) \
+$(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip
$1)_dotdots),.)) \
 $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \
 $($(strip $1)_dotdots)/$($(strip $1)_suffix)

JDK11u
==
diff -r 8599975f5b33 make/common/MakeBase.gmk
--- a/make/common/MakeBase.gmkTue Feb 12 08:40:43 2019 +0100
+++ b/make/common/MakeBase.gmkMon Dec 23 22:10:46 2019 +0100
@@ -611,7 +611,8 @@
 # $2 - Directory to compute the relative path from
 RelativePath = \
 $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \
-$(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip
$1)_prefix)/%, %, $2))) \
+$(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip
$1)_prefix)%, %, $2))) \
+$(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip
$1)_dotdots),.)) \
 $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \
 $($(strip $1)_dotdots)/$($(strip $1)_suffix)

For the second changed hunk, the simple call of the "AssertEquals"
macro had to be renamed to "assert-equals" and wrapped with "eval"
because the corresponding macros haven't been updated in jdk11u yet.
Notice that these are only test changes (for testing the make system
iteslf) and don't effect the build at all.

ORIGINAL

diff -r a82a367b2d8c -r 2ae056696b15 test/make/TestMakeBase.gmk
--- a/test/make/TestMakeBase.gmkMon Jun 03 17:14:23 2019 -0700
+++ b/test/make/TestMakeBase.gmkMon Jun 03 10:28:03 2019 +0200
@@ -361,6 +361,18 @@
 RelativePath, \
 )

+$(call AssertEquals, \
+$(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \
+./banan/kung, \
+RelativePath, \
+)
+
+$(call AssertEquals, \
+$(call 

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

2019-12-30 Thread Sergey Bylokhov

On 12/23/19 9:15 pm, Phil Race wrote:

I am not sure what the right mailing list(s) are for this change.
It definitely isn't a core-libs change. I think build-dev may be better.


Previous changes to these configs were discussed here, so I have send it here 
as well.



I am also unclear when this failure handler is invoked and how all this 
machinery works.

It is only useful for headful tests and so I'd only want it enabled in such a 
case.
And we disable the failure handlers in the headful test jobs anyway because 
they seem
focused on taking pointless core dumps ...> 
So we need something that can be used with headful tests only and doesn't involve

re-enabling the other handlers.

It could be useful for other tests as well and may be able to identify problems 
such as:
 - Suggestions "to open under debugger" from the native asserts
 - Various error dialogs from the OS
And it does not spend much resources compared to current handlers.



Also why exclude Windows ? No easy way to get the screenshot ?


There is no command-line program that can take a screenshot on windows by 
default



-phil.

On 12/11/19 1:00 AM, Sergey Bylokhov wrote:

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233827
Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01

This change adds the "screen capture on the test failure" feature on macOS and 
Linux.
 - On Linux, it is implemented by the "gnome-screenshot" command(in case of
   multiscreen+xinerama    the whole big screen will be saved to the 
"screen.png" file).
 - On macOS it is implemented by the "screencapture" command, note that I have
   used 1 file per screen, if the number of screens less than 5, other files 
will be ignored.






--
Best regards, Sergey.