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