date:20160308

Re: RFR: JDK-8151402: Allow template files from closed and open repos

2016-03-08 Thread Erik Joelsson


Looks ok to me.

/Erik

On 2016-03-08 17:39, Gary Adams wrote:

Here is the proposed update to the GensrcMisc.gmk makefile.

If a closed repos makefile is present, let it provide an alternate 
closed location for
the template files. If it does not exist attempt to use the template 
from the open repos

location.

This change will allow the template files to be located in closed or 
open repos as needed

by the target cross compilation platform.


diff --git a/make/gensrc/GensrcMisc.gmk b/make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk
+++ b/make/gensrc/GensrcMisc.gmk
@@ -22,6 +22,7 @@
 # or visit www.oracle.com if you need additional information or have any
 # questions.
 #
+$(eval $(call IncludeCustomExtension, jdk, gensrc/GensrcMisc.gmk))

 ## 


 # Install the launcher name, release version string, full version
@@ -58,7 +59,9 @@
 OUTPUT_DIR := $(GENSRC_SOR_BIN), \
 PROGRAM := genSocketOptionRegistry))

-SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
+  SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+endif

 ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java: 
$(BUILD_GENSRC_SOR_EXE)

@@ -94,7 +97,9 @@
   OUTPUT_DIR := $(GENSRC_UC_BIN), \
   PROGRAM := genUnixConstants))

-  UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  ifeq ($(wildcard $(UC_PREGEN_FILE)), )
+UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  endif

   ifeq ($(wildcard $(UC_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/fs/UnixConstants.java: 
$(BUILD_GENSRC_UC_EXE)

RFR: JDK-8151402: Allow template files from closed and open repos

2016-03-08 Thread Gary Adams


Here is the proposed update to the GensrcMisc.gmk makefile.

If a closed repos makefile is present, let it provide an alternate 
closed location for
the template files. If it does not exist attempt to use the template 
from the open repos

location.

This change will allow the template files to be located in closed or 
open repos as needed

by the target cross compilation platform.


diff --git a/make/gensrc/GensrcMisc.gmk b/make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk
+++ b/make/gensrc/GensrcMisc.gmk
@@ -22,6 +22,7 @@
 # or visit www.oracle.com if you need additional information or have any
 # questions.
 #
+$(eval $(call IncludeCustomExtension, jdk, gensrc/GensrcMisc.gmk))

 
##
 # Install the launcher name, release version string, full version
@@ -58,7 +59,9 @@
 OUTPUT_DIR := $(GENSRC_SOR_BIN), \
 PROGRAM := genSocketOptionRegistry))

-SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
+  SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+endif

 ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java: 
$(BUILD_GENSRC_SOR_EXE)

@@ -94,7 +97,9 @@
   OUTPUT_DIR := $(GENSRC_UC_BIN), \
   PROGRAM := genUnixConstants))

-  UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  ifeq ($(wildcard $(UC_PREGEN_FILE)), )
+UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  endif

   ifeq ($(wildcard $(UC_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/fs/UnixConstants.java: 
$(BUILD_GENSRC_UC_EXE)

Re: RFR: JDK-8151435: Windows devkit missing 32bit msvcdis120.dll

2016-03-08 Thread Tim Bell


Erik:

The current windows devkit (VS2013SP4) is missing a 32bit version of 
the lib msvcdis120.dll. This dll is needed for the dumbin utility to 
function, which is used in the compare script.This patch modified the 
script we use to generate the devkit to add the missing file.


Bug: https://bugs.openjdk.java.net/browse/JDK-8151435
Patch:
diff -r 2436705f4a75 make/devkit/createWindowsDevkit.sh
--- a/make/devkit/createWindowsDevkit.sh
+++ b/make/devkit/createWindowsDevkit.sh
@@ -74,6 +74,10 @@
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/amd64/
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/amd64/
+# The msvcdis dll is needed to run some of the tools in VC/bin 
but is not

+# shipped in that directory. Copy it from the common dir.
+cp 
"$VS_INSTALL_DIR/Common7/IDE/msvcdis${VS_VERSION_NUM_NODOT}.dll" \

+$DEVKIT_ROOT/VC/bin/
 fi

  



Looks good to me.

Tim

Re: Provide zipped javadoc archive from make

2016-03-08 Thread Erik Joelsson

I wouldn't go that far, but I won't have time to look into it for a 
while yet at least.


/Erik

On 2016-03-08 15:34, Jiri Vanek wrote:

Ping?

Or is this going to be considered closed-wont "fix"?

Thanx!

 J.
On 02/29/2016 04:24 PM, Jiri Vanek wrote:

On 02/26/2016 08:05 PM, Jonathan Gibbons wrote:

On 02/26/2016 03:49 AM, Jiri Vanek wrote:

On 02/25/2016 06:34 PM, Jonathan Gibbons wrote:

On 02/25/2016 09:23 AM, Jiri Vanek wrote:


I must be missing something. Dozens? Of varius runs of javadoc?

I thought that javadoc ending at the end in single drectory is 
one single javadoc for java. If
you are referring to javadoc generated by "per module" then one 
jjoined zip is enough for me.



Jiri,

If you accept the premise  that javadoc writes one stylesheet.css 
file per run of javadoc, take a

look at the following list:


Then my goal will be to crate a trget, which takes
   build/linux-x86_64-normal-server-release/images/docs/
and pack it to
 build/linux-x86_64-normal-server-release/images/javadoc.zip

It should contains also the "smaller api" you are mentioning below? 
If not, then those should

appear in this zip too.


$ find build/linux-x86_64-normal-server-release/images/docs/ -name 
stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css 




build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css 

build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css 





The "main"/"Java SE" javadoc bundle that most are aware of is the 
shortest filename, in the middle
of the list, but there are lots of other smaller APIs that get 
their own doc bundle.  You can

get at
most of them in released doc sets through the top-level "brick 
wall" page, or by using your

favorite
search engine.


Hmm.. Do you have some?  javadoc offline search is quite painful 
think. (Even with new search in
9, which seems to have some troubles on local filesystem). The best 
search engine I know is

(unluckily) https://github.com/judovana/JavadocOfflineSearch


The point of the preceding list was to say that each directory 
containing stylesheet.css is the root
of a separate, distinct, javadoc bundle.  So the smaller APIs that 
get their own bundle are
precisely the ones given in the preceding list, other than the main 
javadoc bundle.


The point of the comment about the brick wall and search engines was 
to indicate how most people
will find these doc bundles in normal use, when they don't have a 
cheat sheet like the list above.


yes I got that. But Then this compressed shattered javadoc needs more 
thoughts.


What is expected format of distribution?
I can imagine: web accessible, unapcked "all docs" and "zipepd "all 
docs".

But never several zips, or several directories.

What is what I'm missing behind this effort to deliver javadocs 
per-module?




As far as IDEs wanting to access javadoc bundles, I would expect 
that to make all the docs
available, you would want to zip up *each* directory containing 
stylesheet.css given in the
preceding list. If you just zip up the top API directory, sure, that 
will include all the files, but
the reality is that the IDE will likely not have any way of knowing 
about the minor doc bundles in

all jre/ and jdk/ directories and subdirectories.


Indeed, when you pack top level javadoc directroy as top level of 
archive (so javadco will become
zipped1.zip!javadoc) then indeed, Netbeasn refuse to load it wh

Re: Provide zipped javadoc archive from make

2016-03-08 Thread Jiri Vanek


Ping?

Or is this going to be considered closed-wont "fix"?

Thanx!

 J.
On 02/29/2016 04:24 PM, Jiri Vanek wrote:

On 02/26/2016 08:05 PM, Jonathan Gibbons wrote:

On 02/26/2016 03:49 AM, Jiri Vanek wrote:

On 02/25/2016 06:34 PM, Jonathan Gibbons wrote:

On 02/25/2016 09:23 AM, Jiri Vanek wrote:


I must be missing something. Dozens? Of varius runs of javadoc?

I thought that javadoc ending at the end in single drectory is one single 
javadoc for java. If
you are referring to javadoc generated by "per module" then one jjoined zip is 
enough for me.



Jiri,

If you accept the premise  that javadoc writes one stylesheet.css file per run 
of javadoc, take a
look at the following list:


Then my goal will be to crate a trget, which takes
   build/linux-x86_64-normal-server-release/images/docs/
and pack it to
 build/linux-x86_64-normal-server-release/images/javadoc.zip

It should contains also the "smaller api" you are mentioning below? If not, 
then those should
appear in this zip too.


$ find build/linux-x86_64-normal-server-release/images/docs/ -name 
stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css


build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css



The "main"/"Java SE" javadoc bundle that most are aware of is the shortest 
filename, in the middle
of the list, but there are lots of other smaller APIs that get their own doc 
bundle.  You can
get at
most of them in released doc sets through the top-level "brick wall" page, or 
by using your
favorite
search engine.


Hmm.. Do you have some?  javadoc offline search is quite painful think. (Even 
with new search in
9, which seems to have some troubles on local filesystem). The best search 
engine I know is
(unluckily) https://github.com/judovana/JavadocOfflineSearch


The point of the preceding list was to say that each directory containing 
stylesheet.css is the root
of a separate, distinct, javadoc bundle.  So the smaller APIs that get their 
own bundle are
precisely the ones given in the preceding list, other than the main javadoc 
bundle.

The point of the comment about the brick wall and search engines was to 
indicate how most people
will find these doc bundles in normal use, when they don't have a cheat sheet 
like the list above.


yes I got that. But Then this compressed shattered javadoc needs more thoughts.

What is expected format of distribution?
I can imagine: web accessible, unapcked "all docs" and "zipepd "all docs".
But never several zips, or several directories.

What is what I'm missing behind this effort to deliver javadocs per-module?



As far as IDEs wanting to access javadoc bundles, I would expect that to make 
all the docs
available, you would want to zip up *each* directory containing stylesheet.css 
given in the
preceding list. If you just zip up the top API directory, sure, that will 
include all the files, but
the reality is that the IDE will likely not have any way of knowing about the 
minor doc bundles in
all jre/ and jdk/ directories and subdirectories.


Indeed, when you pack top level javadoc directroy as top level of archive (so 
javadco will become
zipped1.zip!javadoc) then indeed, Netbeasn refuse to load it whole 9just few 
parts)

However when you pack it  that content of javadoc will be the top of the archive
(zipped2.zip!{api,jdk,jre,platform}) then NB loads it fine.

If even this is wrong, th

RFR: JDK-8151435: Windows devkit missing 32bit msvcdis120.dll

2016-03-08 Thread Erik Joelsson


Hello,

The current windows devkit (VS2013SP4) is missing a 32bit version of the 
lib msvcdis120.dll. This dll is needed for the dumbin utility to 
function, which is used in the compare script.This patch modified the 
script we use to generate the devkit to add the missing file.


Bug: https://bugs.openjdk.java.net/browse/JDK-8151435
Patch:
diff -r 2436705f4a75 make/devkit/createWindowsDevkit.sh
--- a/make/devkit/createWindowsDevkit.sh
+++ b/make/devkit/createWindowsDevkit.sh
@@ -74,6 +74,10 @@
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/amd64/
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/amd64/
+# The msvcdis dll is needed to run some of the tools in VC/bin but 
is not

+# shipped in that directory. Copy it from the common dir.
+cp "$VS_INSTALL_DIR/Common7/IDE/msvcdis${VS_VERSION_NUM_NODOT}.dll" \
+$DEVKIT_ROOT/VC/bin/
 fi

Re: RFR: JDK-8151402: Allow template files from closed and open repos

RFR: JDK-8151402: Allow template files from closed and open repos

Re: RFR: JDK-8151435: Windows devkit missing 32bit msvcdis120.dll

Re: Provide zipped javadoc archive from make

Re: Provide zipped javadoc archive from make

RFR: JDK-8151435: Windows devkit missing 32bit msvcdis120.dll

6 matches

Site Navigation

Mail list logo

Footer information