Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

[Kelly O'Hair]

Something in the back of my mind says that there has to be a better solution to this X11 sizeof issue, but
at the same time, I don't think we need to find that solution now.

I notice that some of the $@.tmp stuff has been removed, along with the "$(RM) $@ $@.tmp" commands.
I know it's a pain to do this, but I have found it necessary, especially on Windows for some reason.

The "$(MKDIR) -p $(@D)" guarantees that the destination directory exists, glad those remain.
The "$(RM) $@" is done to make sure the target file is removed so we get a fresh file. If some command
in the rules fail, I'd rather not see some partial $@ file left around from some previous build.
The use of $@.tmp files, followed by a "$(MV) $@.tmp $@" was to avoid any issues with a partially
constructed $@ file being left around, perhaps when some command in the rules got killed by a ^C or 'kill -9',
and a second make command thinking the file did not need to be built.
I suppose these habits are paranoid, but it's what I've done in the past to guarantee predictability.
If there is a better way to do this I am all ears.

-kto

On Nov 29, 2012, at 6:27 AM, Fredrik Öhrström wrote:

> The GensrcX11Wrapper.gmk makefile creates a new sizes.32 or sizes.64 by running a generated C program
> that performs many sizeof calculations on X11 structures. This is cross compileable.
> 
> Fortunately the sizes.32 and sizes.64 offset files are very stable. Thus we can commit them to the
> source code repository. When not cross compiling we perform a verification step that
> regenerates the offset file for the build platforms bits, and checks that it is the same
> as the committed version.
> 
> Patch is here:
> http://cr.openjdk.java.net/~ohrstrom/webrev-8004151-gensrcX11wrapper/
> (do not read the diff of the makefile, read the new makefile, too many changes.)
> 
> Question: by always supplying both sizes.32 and sizes.64 to the generator tool, it
> seems like it is encoding both offsets into the java classes. This might not always
> have been done before. Good or bad?
> 
> //Fredrik