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 JDK 8 "new
build" and it will be the case here too. So if there aren't any blocking
issues then I think the best thing is to work on those in jdk9/dev once
the changes get there, otherwise I suspect we will iterate on this for a
long time (and as I'm sure you can appreciate, it is painful to have to
keep thousands of lines of make file changes in a side forest while the
main line churns).
:
* 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 several occasions of such
statements. In some cases, it seems like dead code that can (and
should) be removed. But in some cases, I believe it is an indication
that the source code has still not yet been moved to a suitable
location. I believe the end goal with this shuffling regarding native
library source code is that there should be a one-to-one
correspondance between compiled native library and source code
directory. This is now indeed the case for 99% of the libraries, but
there are still some exceptions.
I assume you are referring to the rename of src/solaris to src/unix,
something that was long overdue in the jdk repository. The intention is
that eventually each area will go through their source files in
src/$MODULE/unix and move any source files that are Linux, Solaris or OS
X specific to the appropriate src/$MODULE/$OS tree. We've done it for a
few libraries (such as libnio) so several EXCLUDE_FILES are already
removed, the remainder of the exceptions will happen in time.
:
* Finally, I'm also not entirely happy with the placement of
modules.xml in the root directory. Erik has told me that the intention
is that this file will ultimately be created dynamically at build
time, and when that happens, it will just be a build by-product which
can be placed elsewhere. If this is indeed the case, I can live with
some temporary extra cluttering of the top-level directory
The top-level directory is intentional. It's not worth getting hung up
on it because it is temporary (as noted in the JEP) and so will go away
once we are further down the road on having a module system in JDK 9.
-Alan.
