LIBARCH replacement?

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Fri Oct 5 02:28:30 PDT 2012


On 2012-10-05 06:09, David Holmes wrote:
> I now see this set of definitions in spec.gmk for a 32-bit x86 build:
>
> OPENJDK_TARGET_CPU:=x86
> OPENJDK_TARGET_CPU_ARCH:=x86
> OPENJDK_TARGET_CPU_BITS:=32
> OPENJDK_TARGET_CPU_ENDIAN:=little
> OPENJDK_TARGET_CPU_ISADIR:=
> OPENJDK_TARGET_CPU_LIBDIR:=/i386
> OPENJDK_TARGET_CPU_LEGACY:=i586
> OPENJDK_TARGET_CPU_LEGACY_LIB:=i386
> OPENJDK_TARGET_CPU_OSARCH:=i386
> OPENJDK_TARGET_CPU_JLI_CFLAGS:=-DLIBARCHNAME='"i386"'
>
> and it is far from clear which variable is meant to represent which 
> kind of "arch" usage. In particular LIBARCH very clearly meant "the 
> <arch> directory found in the lib directory". 

It might be "very clearly" so to those versed in the old system, and 
maybe not to everyone else. :-) But let's not argue about that.

Anyway, the platform naming proliferation is a real problem in the code 
base. I tried to at least gather all of the platform definitions in one 
place and with a common name prefix. However, since that itself is quite 
lengthy, it was a bit problematic to find good names. A name like 
OPENJDK_TARGET_CPU_LEGACY_USED_FOR_THE_ARCH_DIRECTORY_FOUND_IN_THE_LIB_DIRECTORY 
would certainly be descriptive, but not very practical. Keeping names 
like "LIBARCH" might be good for conversion from the old style, but they 
will still have the same non-obviousness to their names for new users.

> But which of the above should be used to replace LIBARCH? The 
> candidates (based on the fact they have the right value) are:
>
> OPENJDK_TARGET_CPU_LIBDIR:=/i386
> OPENJDK_TARGET_CPU_LEGACY_LIB:=i386
> OPENJDK_TARGET_CPU_OSARCH:=i386
>
> I suspect the first one was the intended replacement - right? 

Check in hotspot-spec.gmk.in what it says at the line LIBARCH=@... at . 
(Sorry I'm at home and do not have access to the source today.)

> But the leading slash is problematic for my usage (hence I've used the 
> second one). I don't think slashes belong in simple variables.

The reason for the slash is that on some platforms (read: macosx, and 
possibly Windows (don't remember)) this value is empty, since there is 
no specific sub-directory the files should be put in. This is similar to 
the ..._ISADIR variable. I tried to name stuff "-DIR" when they included 
a slash to at least get some consistency in this mess.

/Magnus



More information about the build-infra-dev mailing list