RFR: JDK-8025715 Split CompileNativeLibraries.gmk

[Erik Joelsson]

I like the split and think this looks good.

/Erik

On 2013-10-15 10:57, Magnus Ihse Bursie wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025715
>
> The file CompileNativeLibraries.gmk is by far the longest (roughly 150 
> kB) and most unstructured file in the new build system. It ended up 
> being the "default" place to put make logif for all native libraries 
> in the JDK during the conversion to the new build system, and -- 
> despite talk about doing something about this -- we never came around 
> to sort this out until now.
>
> The current file is a collection of all the ~50 libraries in JDK, in 
> more or less random order. What can we do about that?
>
> One suggestion is to create one file per library generated. This gives 
> a clear and unambigious definition on where to find each library. I 
> started on this approach, but found that a directory full of mostly 
> minimal files, where the code was just about as long as the copyright 
> header, while better than the original mess, was not really optimal. 
> Also, due to the tight coupling between some related libraries, it was 
> hard to avoid some code duplication in this case as well.
>
> So, moving on to another solution, to split the file into "logical 
> chunks". While inherently somewhat more subjective than the strict 
> rule above, I believe this results in a much clearer code base. I 
> ended up with 8 files; two of them generic (one of them generic, and 
> one for platform-specific "glue"), and the rest more or less 
> corresponding to the teams working on that part of the code.
>
> The list of files looks like this:
>
> * lib/CoreLibraries.gmk
> * lib/PlatformLibraries.gmk
> * lib/NetworkingLibraries.gmk
> * lib/NioLibraries.gmk
> * lib/SecurityLibraries.gmk
> * lib/ServiceabilityLibraries.gmk
> * lib/Awt2dLibraries.gmk
> * lib/SoundLibraries.gmk
>
> And this is the libraries that they contain:
>
> * lib/CoreLibraries.gmk
> BUILD_LIBFDLIBM
> BUILD_LIBFDLIBM_MAC
> BUILD_LIBVERIFY
> BUILD_LIBJAVA
> BUILD_LIBZIP
> BUILD_LIBUNPACK
> BUILD_LIBJLI
> BUILD_LIBJLI_STATIC
> BUILD_LIBNPT
>
> * lib/PlatformLibraries.gmk
> BUILD_LIBAPPLESCRIPTENGINE
> BUILD_LIBOSXAPP
> BUILD_LIBOSX
> BUILD_LIBJOBJC32
> BUILD_LIBJOBJC64
> BUILD_JAWTACCESSBRIDGE$1
> BUILD_JAVAACCESSBRIDGE$1
> BUILD_WINDOWSACCESSBRIDGE$1
>
> * lib/NetworkingLibraries.gmk
> BUILD_LIBNET
>
> * lib/NioLibraries.gmk
> BUILD_LIBNIO
> BUILD_LIBSCTP
>
> * lib/SecurityLibraries.gmk
> BUILD_LIBJAAS
> BUILD_LIBJ2PCSC
> BUILD_LIBJ2GSS
> BUILD_LIBKRB5
> BUILD_LIBSUNMSCAPI
> BUILD_LIBJ2PKCS11
> BUILD_LIBSUNEC
> BUILD_LIBJ2UCRYPTO
>
> * lib/ServiceabilityLibraries.gmk
> BUILD_LIBATTACH
> BUILD_LIBDT_SOCKET
> BUILD_LIBDT_SHMEM
> BUILD_LIBJDWP
> BUILD_LIBJSDT
> BUILD_LIBINSTRUMENT
> BUILD_LIBMANAGEMENT
> BUILD_LIBHPROF
> BUILD_LIBJAVA_CRW_DEMO
> BUILD_LIBJFR
>
> * lib/Awt2dLibraries.gmk
> BUILD_LIBMLIB_IMAGE
> BUILD_LIBMLIB_IMAGE_V
> BUILD_LIBAWT
> BUILD_LIBAWT_XAWT
> BUILD_LIBLCMS
> BUILD_LIBJPEG
> BUILD_LIBFONTMANAGER
> BUILD_LIBT2K
> BUILD_LIBJAWT
> BUILD_LIBKCMS
> BUILD_LIBSUNWJDGA
> BUILD_LIBAWT_HEADLESS
> LIBSPLASHSCREEN
> BUILD_LIBDCPR
>
> * lib/SoundLibraries.gmk
> BUILD_LIBJSOUND
> BUILD_LIBJSOUNDALSA
> BUILD_LIBJSOUNDDS
>
> With this split, the file sizes range from 4k-18k, with the exception 
> of Awt2d.gmk which is 49k.
>
> I tried to separate Awt2d.gmk into an Awt.gmk and a 2d.gmk, with 
> guidance from http://openjdk.java.net/groups/2d/2dawtfiles.html, but I 
> failed. As I interpreted this list, while some of the libraries seem 
> to be strictly 2d, the rest seems to be a mix of awt and 2d, making a 
> separation seemingly a bit artificial. It is possible someone from the 
> AWT and 2d teams could bring some insight. On the other hand, this 
> might also be a clue that they do belong together -- for a separation 
> to be meaningful I believe it should be at least reasonably 
> understandable by most developers.
>
> I have created the new files by copying CompileNativeLibraries.gmk, 
> and then deleting each library from all files except the one it 
> belonged to, so each file is a unique "order intact" subset of the 
> original file. The purpose of this was mainly to facilitate reviewing 
> -- all changes will look like deletion, and it is easy to verify that 
> the actual code has not inadvertently changed. (Except for a few 
> places where I corrected bad indentation.)
>
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8025715-split-CompileNativeLibraries/webrev.01
>
> /Magnus