On 2014-08-28 21:36, Phil Race wrote:
>./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
Is a tool that is run manually when we need to re-generate the shaders.
It is co-located so that can be found easily. It certainly should not be
deleted, nor should it be moved anywhere obscure.
Oh,
On 2014-08-28 21:40, Phil Race wrote:
On 8/28/2014 12:36 PM, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun
On 28/08/2014 20:36, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package ..
On 8/28/2014 12:36 PM, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package .
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package .. and
people won't always be running in j
Thanks!
--
best regards,
Anthony
On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
On 2014-08-27 12:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AW
On 2014-08-27 12:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
opengl-related files) even though they're co
On 27/08/2014 11:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
opengl-related files) even though they're co
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and opengl-related
files) even though they're compiled into the awt native libraries.
--
b
On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
On 2014-08-18 16:15, Anthony Petrov wrote:
So I'm not sure if the current set of AWT libraries could be
simplified any further.
Hope this helps.
Thank you for the clarification, it was very helpful!
While the set of AWT libraries probably canno
On 18/08/2014 14:56, Magnus Ihse Bursie wrote:
:
* In CompileDemos, we create demo/jpda/src.zip. This includes source
code from src/demo/share (expected), but also from
jdk/src/jdk.jdi/share/classes/com/sun/tools/example/... (unexpected!).
Should example code really live in the jdk.jdi packag
On 2014-08-15 10:52, Magnus Ihse Bursie wrote:
These are indeed the single most significant changes to the build
system since the "new" build system was introduced.
Here follows a partial review of the changes in the jdk repo. Even
though it's long, I'm not done. ;-)
While this has turned in
On 2014-08-18 16:15, Anthony Petrov wrote:
On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
libawt et al:
The relation between libawt, libawt_headless, libjawt, libawt_xawt
and libawt_lwawt are hairy enough to make my brain curl up. I believe
there are simplifications to be made but I gave up
Hello,
The basic rule for the new source layout is that for each library, there
is a directory where all sources for that library go. This was hard to
apply to libawt and friends since as you say, some files go in libawt on
windows and libawt_xawt on linux and solaris. For now, I put those in
On a related note I am scratching my head about why some files
destined to be compiled into libawt or libawt_xawt go into a directory
called 'common'.
Eg OpenGL sources are in common but aren't common to all libs
or even to all awt libs, since they would go into libawt on windows
and libawt_xawt o
* Magnus Ihse Bursie [2014-08-18 09:48]:
> liblcms:
> The include file picking of LCMS.c would not be needed if the upstream
> lcms source code were moved into a separate subdirectory of liblcms.
>
> libjavajpeg:
> If the upstream IJG jpeg library were moved into a subdirectory, the
> explici
On 16/08/2014 1:58 AM, Erik Joelsson wrote:
Hello Omair,
No, as I tried to explain in my initial mail on this thread, since the
modules are all compiled in parallel, and not sequentially like the
current build does with the repositories, it doesn't make much sense
timing each module. The numbers
On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
libawt et al:
The relation between libawt, libawt_headless, libjawt, libawt_xawt
and libawt_lwawt are hairy enough to make my brain curl up. I believe
there are simplifications to be made but I gave up trying to figure them
out.
libawt contains
I also found these random notes scribbled down that I forgot to add to
the previous mails:
* In CoreLibraries.gmk, we have dead code defining BUILD_LIBVERIFY_SRC
which is not used anymore.
* In Tools.gmk, I notice that we copy the files
$(JDK_TOPDIR)/src/java.desktop/share/classes/javax/sw
On 2014-08-15 12:13, Magnus Ihse Bursie wrote:
Here are the more concrete specification of this, for all files except
Awt2dLibraries.gmk, which I'll return to.
And here is the jury's verdict on Awt2dLibraries.gmk. :-)
libjavajpeg:
One of these are not needed:
LIBJAVAJPEG_SRC :=
$(JDK_TOP
On 8/15/14, 3:13 AM, Erik Joelsson wrote:
* GensrcCLDR.gmk is not ideal. It generates source for multiple
modules, and the output is separated afterwards. Fixing this will
probably means some modification to the java helper tools.
While I think it would be good to split this in principle, I'm n
Yes, we (the LangTools team) are on our own for this file. Jan Lahoda
did some work to update the build.xml file for us. At some point we may
want to do more surgery on this file, but that is a discussion for the
LangTools team to have.
-- Jon
On 08/15/2014 06:17 AM, Erik Joelsson wrote:
On 8/12/2014 7:10 AM, Chris Hegarty wrote:
Webrevs:
http://cr.openjdk.java.net/~chegar/8054834/00/
I reviewed the hotspot change. Looks good. One minor point:
I think line 1230 can be removed when rt.jar is present.
Mandy
Hello Omair,
No, as I tried to explain in my initial mail on this thread, since the
modules are all compiled in parallel, and not sequentially like the
current build does with the repositories, it doesn't make much sense
timing each module. The numbers would be meaningless.
/Erik
On 2014-08
Hi,
* Alan Bateman [2014-08-13 08:36]:
> Just to add to Chris and Erik's mails, I would encourage everyone that
> pushes to jdk9/dev or the other jdk9 project integration forests to clone
> and build jigsaw/stage and get familiar with the proposed layout, new build
> targets, and the very differe
On 8/15/2014 1:49 AM, Magnus Ihse Bursie wrote:
*** Issues regarding modules.xml ***
The new modules.xml and associated Java tools and make files seems
rather confusing to me. I understand some of the mysteries here are
due the the fact that the file has moved around during development.
Neve
Quick update:
I downloaded the jigsaw stage repo and tried the build. The biggest
issue is that it requires Ant 1.9.4 (because of the MuliRootFileSet) to
work, but after that is set up, everything works like before. My
IntelliJ setup needed few cosmetic changes, to update the source roots,
but
On 15/08/2014 09:49, Magnus Ihse Bursie wrote:
These are indeed the single most significant changes to the build
system since the "new" build system was introduced.
Indeed, some of us have been referring to this as the "new new build".
As I recall there was a tail of issues and clean-ups for the
I'm looking at the langtools-related changes in build.xml; I what is the
degree of support available in the build.xml ant file for the Jigsaw
world? It seems to me that not all the target would function and it also
seems that some of the properties previously encoded in a side property
file (ma
On 2014-08-15 14:54, Maurizio Cimadamore wrote:
I'm looking at the langtools-related changes in build.xml; I what is
the degree of support available in the build.xml ant file for the
Jigsaw world? It seems to me that not all the target would function
and it also seems that some of the properti
On 15/08/2014 11:13, Magnus Ihse Bursie wrote:
:
In NetworkingLibraries.gmk:
* There are multiple instances of this pattern:
ifneq ($(OPENJDK_TARGET_OS), solaris)
LIBNET_EXCLUDE_FILES += solaris_close.c
endif
The correct solution is to move the corresponding files away from the
"un
Hello, Magnus
Thanks for the thorough review. I tend to agree with Alan, that we
should rather push this in unless we find critical issues but make sure
to continue cleaning this up in jdk9/dev. I have created bugs for
(almost) everything you have listed below. See inline for links and
commen
On 2014-08-15 10:52, Magnus Ihse Bursie wrote:
*** Issues with source files moving and its repercussions ***
* When the source code has moved, especially the native libraries,
most of the specific INCLUDE and EXCLUDE statements are, or should be,
unnecessary. Nevertheless, there are still sev
On 2014-08-12 16:10, Chris Hegarty wrote:
This is a review request for the Initial changes for JEP 201: Modular Source
Code [1].
There are a number of individuals responsible for these changes. Some, possibly
not all, are explicitly listed in the To section of this mail, and they will
help ad
On 2014-08-14 09:07, Erik Joelsson wrote:
- javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant)
JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG?
I agree, but that should be a separate change.
Actually, the variable JAVA already contains the big java flags. The
correct fix here
Hello Mike,
Thanks for the comments. See inline.
On 2014-08-13 23:29, Mike Duigou wrote:
There's a lot to review here. This is not a complete review but hopefully contributes to
our review "coverage". I am focusing on the top project in this set of comments.
- --with-output-sync seems like it
On 13/08/2014 22:29, Mike Duigou wrote:
:
- modules.xml "Changes to this file will require review by Committers to Project
Jigsaw." Will this be true after integration into jdk9/dev repo?
There's a section in JEP 200 about modules.xml, it is temporary until
there is a module system in place.
There's a lot to review here. This is not a complete review but hopefully
contributes to our review "coverage". I am focusing on the top project in this
set of comments.
- --with-output-sync seems like it should be on by default if available.
Downside? This could also be split out from the jigs
Thanks for the explanation Erik.
I have taken a pass over the changes, and they look ok to me ( I am
happy to be listed as a reviewer ). I also did several build and test
runs on Solaris, Linux, Max OSX, and Windows. All look good.
I am seeing, in some cases, about a 20% reduction in image bu
On 2014-08-13 14:17, Chris Hegarty wrote:
Thanks for the explanation Erik.
I have taken a pass over the changes, and they look ok to me ( I am
happy to be listed as a reviewer ). I also did several build and test
runs on Solaris, Linux, Max OSX, and Windows. All look good.
I am seeing, in some
Just to add to Chris and Erik's mails, I would encourage everyone that
pushes to jdk9/dev or the other jdk9 project integration forests to
clone and build jigsaw/stage and get familiar with the proposed layout,
new build targets, and the very different output emitted during the
build. The cha
I should probably write something about the rather extensive changes to
the build logic in this patch.
As the source gets organized around modules, it made sense to also
organize the build more around modules. In this patch, the makefiles
have in large parts been split into module specific fil
This is a review request for the Initial changes for JEP 201: Modular Source
Code [1].
There are a number of individuals responsible for these changes. Some, possibly
not all, are explicitly listed in the To section of this mail, and they will
help address any comments arising from this review
43 matches
Mail list logo
