Review Request: Build-infra M1

[David Holmes]

Hi Fredrik,

On 22/03/2012 5:05 PM, Fredrik Öhrström wrote:
> ----- david.holmes at oracle.com skrev:
>> 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.

I couldn't access /home/ohrstrom either :(

I guess this needs to be taken up internally to see how this build-deps 
stuff is to be setup, configured, and maintained. Something for M2 perhaps.

> Sounds silly to cross compile from x64 to ia32, yes, but the command above

Not silly at all, we have an issue with that right now.

> 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.

Ok, so as Erik added we're not quite there yet - but the pieces are 
lining up.

>> 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.

Ok I see how src/closed is handled. What I can't see is how make/closed 
is handled, or more specifically how we factor out proprietary details 
into a distinct set of closed "makefiles".

>> 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.)

Yes - Guilty as charged - I have a PDF somewhere. But it was a general 
question for everyone's benefit.

Plus, if I run configure from common/makefiles that does not become the 
outputdir, it instead creates a top-level build directory in the repo 
(though config.log and config.status do pollute the current directory).

>> 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

I'll take that as a "No". ;-)

>> 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.

Thanks for the pointer. It is not evident from the the webrev where/how 
these get used.

>> 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.

The question was why do I have to cd into common/makefiles to run the 
configure script. I think the answer is "because if you are in 
common/makefiles then a build directory will be created at the top-level 
of the repo forest; otherwise the pwd will be treated as the intended 
outputdir".

Thanks,
David

>
> //Fredrik