----- david.hol...@oracle.com skrev: > My major concern with the transition here is being able to take > existing knowledge of the build system and be able to figure out where in the > new system certain things are handled. How can I tell if a Makefile is > part of the old build or the new build? Are some both?
You read the file named "LegacyMakefiles.gmk" and you will understand that the contents of java, javax, sun and com contain the remaining legacy makefiles. The contents of these will be brought up to the makefiles toplevel and put into CompileNativeLibraries and or some of the other toplevel makefiles. This coming together is a necessary step to add correct dependencies and to prepare for the Jigsaw split into modules in the future. > It is still unclear to me how cross-compilation is to be set up. You can cross compile from x64 linux to ia32 linux, with the following commandline: ../autoconf/configure \ --host=i686-unknown-linux-gnu \ --with-builddeps-conf=/home/ohrstrom/jdk8/common/autoconf/builddeps.conf.example \ --with-builddeps-server=buildtools.se.oracle.com/buildtools/openjdk \ --with-builddeps-dir=/home/ohrstrom/builddeps \ --with-jvm-variants=client,server For those outside of Oracle, the builddeps server is not available, you have to have i686-unknown-linux-gnu-gcc et al in your path, and drop the builddeps options. Sounds silly to cross compile from x64 to ia32, yes, but the command above exercising everything that is needed for cross compilation. What remains is to find the correct CC for compiling to/for the build platform (legacy name HOSTCC), in configure for the hotspot build. By running from x64 linux to ia32 linux, I cheat since the i686-unknown-linux-gnu-gcc works for the build platform as well. > It is unclear to me how the src/closed and make/closed repositories > are supported/handled. Going forward much of what pertains to Oracle JDK > proprietary features, should be moved out of the OpenJDK repository in > my opinion. The new makefiles do build the closed jdk, even though it has to use the current totally broken way of injecting source code repositories smack in the middle of the openjdk sources. Of course, there should be no trace of closed jdk code, neither in the makefiles, nor in the source code. And there is a solution for this in the configure script, ie the add/override source roots commands. But that potential solution is irrelevant as long as the open/closed source code repositories are structured the way they are. > > Is there a cheat sheet for how to run configure? There are many > options > that seems completely irrelevant to what would normally be part of a > JDK > build; conversely some obvious flags seem to be missing eg > ALT_OUTPUTDIR. You set the OUTPUTDIR by running the configure script from the outputdir, then run make from the outputdir. This was explained during the tech talk and the information was available to you as a pdf. (Since you refused to have a paper version sent to you.) > Is it intended that any single person actually understand the contents > of configure and need to edit it? It has strange contents (like > multiple > file copyright headers in places ???). Reading the configure script is like reading the bytecode of a Java program or reading the machine code generate from a c-compiler. Go ahead if you want to, but most people would prefer to read the source. ie configure.ac > The BUILD_HEADLESS_ONLY option is not for what it has been used. A > normal JDK build will build a JDK that has both headful and headless > support (property: java.awt.headless=true). The BUILD_HEADLESS_ONLY > flag > was an artifact from our embedded build systems for use on platforms > where it was simply not possible to build anything pertaining to the > GUI > systems ie no X11 headers or libraries. As has been pointed out > recently > BUILD_HEADLESS_ONLY doesn't actually work in current jdk8 (and likely > jdk7 too). Undoubtedly. But this is one of many,many typical problems when digging through the current makefiles. A lot of options, like env variables, that are not commented, have no verification if they are set correctly, and in some cases, do not even work. Clearly it would be beneficial to be able to build a headless version of the jdk. Thus the option exists in the configure script. If the original makefiles are broken, well that is just something that we need to fix. > common/makefiles/Makefile > I may be misreading something but the help has > 161 $(info make ALL # build images for all > configurations) > but the all: target only builds jdk, not images. True, a mistake in the comment. I'll fix. > > common/makefiles/compress.post > common/makefiles/compress.pre > ??? These are just weird. What role do they serve? Were they > autogenerated? > common/makefiles/uncompress.sed > ??? what is this? Is it autogenerated? How do I know if I need to add > anything to it? > If you read the comments in the Makefile where these commands are put to use, You will find in MakeBase.gmk that these tools are necessary to workaround command line length limitations on platforms like Solaris and Cygwin. > Does this pertain only to the new javac server or is this a general > enhancement to javac for 8? It is an enhancement for jdk8. > Why do I have to cd to common/makefiles ? Because we want to keep the original makefiles in place, for the time being. Thus the new build system does not affect the old build system at all. //Fredrik
