bsd.java.mk 2.0

[Herve Quiroz]

Here it is!


Finally, I had to remove some of Ernst's JDK port detection. Enrst told
that in was quite complex to maintain anyway (even sent a PR BTW). So
what v2.0 just does is to first detect if we are using v1.0 or v2.0. In
the former case, it sets the right variables to be able to use v2.0 for
the rest of JDK port detection.

Then as I said in a previous mail, it builds a list of all suitable JDK
ports:

_JAVA_PORTS_BY_VERSION contains all JDK ports that are suitable
according to their version number.

_JAVA_PORTS_BY_OS contains all JDK ports that are suitable according to
the OS they use (native, linux).

_JAVA_PORTS_BY_VENDOR contains all JDK ports that are suitable according
to their vendor (freebsd, sun, blackdown, ibm)

Then we put in _JAVA_PORTS_POSSIBLE any port that is present in each of
BY_VERSION, BY_OS and BY_VENDOR (which means it's a suitable JDK port
on every aspect).

We first try to find an already installed JDK port that is in present in
_JAVA_PORTS_POSSIBLE. If we find one, we mark it as the JDK port to use
as a dependcy. If we can't find one, we take the first one from the
list.

<TODO> Implement a mechanism to enforce a particular order of preference
between possible ports. For now, we just use alphanumeric sorting which
has (we get lucky here) all of the native/FreeBSD JDK ports first.  But
we should do something to avoid mistakes in the future. </TODO>

When we have elected our JDK port, we set the variables relative to
version, JAVA_HOME, OS, vendor...

JAVA_PORT is the name of the port (ex: java/jdk14)
JAVA_HOME is the home of the port in the local base.
JAVA_PORT_VERSION is the version of the port (ex: 1.4)
JAVA_PORT_OS is the OS used by the port (ex: Linux)
JAVA_PORT_VENDOR is the vendor of the prot (ex: Sun)

Everything is extracted from some JDK port metadata stored in
bsd.java.mk itself.

BTW, I changed all JAVA_PORT_SUN_LINUX_n_n to JAVA_PORT_LINUX_SUN_n_n
(the same goes for IBM_LINUX and BLACKDOWN_LINUX) so the name of the
variables used in bsd.java.mk match the actual name of the JDK ports.
That's just internal stuff so it won't change anything for the porters
or end-users.

The final stage (dependency issues such as CLASSPATH, javac/jikes...) is
unchanged, altough I fixed a few things (when NO_BUILD is set,
NO_BUILD_DEPENDS_JAVA is implicit).

-----------------

HOWTO for porters:

You may use bsd.java.mk v2.0 as v1.0, as it is fully backward
compatible. Anyway, you should note that I strongly encourage the use of
the 2.0 features (as I spent quite some of my sleeping time on it
those last two days).

Regarding v2.0 JDK port dependency automated detection:

When USE_JAVA is set and does not reference a version number (in such a
case it sould mean we are still using v1.0), the following vaariables
may be set in order to give to precision of the requirements of the
port:

 - JAVA_VERSION:

A list of space-separated suitable java versions for the port
building/running. As it was the case with v1.0, an optinal "+" allows
you to specify a range of versions. For example,

	JAVA_VERSION= 1.1 1.3+

means that all Java 1.1 ports as well as all Java ports with a version
number greater or equal to 1.3 are suitable. Which means the following
versions are okay: 1.1 1.3 1.4

When nothing is specified, bsd.java.mk considers that all version
numbers are suitable.


 - JAVA_OS:

A list of space-separated suitable JDK port OS for the port
building/running. Currently, two values are supported: 'native' and
'linux'. For example,

	JAVA_OS= native

means that all native ports are suitable for this port.

When nothing is specified, bsd.java.mk considers that all JDK are
suitable according to their OS.


 - JAVA_VENDOR:

A list of space-sperated suitable JDK port vendors for the port
building/running. Currently, four values are supported: 'freebsd',
'sun', 'ibm' and 'blackdown' (warning it is currently case-sensitive but
may be improved in a future release).

When nothing is specified, bsd.java.mk considers that all JDK are
suitable according to their vendor.


 - JAVA_BUILD:

When set, it means that the elected JDK port should be added to build
dependencies for the port as it will be needed to build it.

In future releases of bsd.java.mk v2.0, it is planned to support two
values for JAVA_BUILD: 'jdk' and 'jre' to specify the nature of the Java
port used to build the current port. For now, we just have JDKs so it is
not so important IMHO.


 - JAVA_RUN:

This variable works exactly the same as JAVA_BUILD but regarding run
dependencies.

Currently, and for backward compatibilty with v1.0, when neither
JAVA_RUN nor JAVA_BUILD is set, we assume that we still use v1.0 way of
specifying build/run Java dependencies. In such a case, we refer to the
variables NO_RUN_DEPENDS_JAVA and NO_BUILD_DEPENDS_JAVA for this
purpose.


-----------

Now I will speak about the testing phase. This will probably be trivial
because of the backward compatibility. I encourage people to just change
their Mk/bsd.java.mk and try to deinstall/reinstall Java ports to see if
it still works. I have only got two FreeBSD machines (and one is my
office system which is quite critical) so I couldn't test it further.

To test the new features in v2.0, I have included in the archive a patch
for two existing ports, java/jakarta-commons-cli and java/trove4j. The
former is a demonstration of "build and run" Java dependency and the
later is "run only" Java dependency.

In my opinion, as soon as we get things okay for ports, we will be able
to use bsd.java.mk for JDK ports themselves. That was the idea for
bsd.java.mk in the first as it refers to a PR regarding "java/jdk13 does
not correctly detects itself for native bootstrap" IIRC (I am too lazy
to scan the PR and mailing archives at the moment).

On the TODO list is also the portlint issue. We could possibly contact
the maintainer of devel/portlint to have all bsd.java.mk v1.0 uses in a
port generating a warning ("Deprecated feature").

But maybe the quick patch of all java ports actually using bsd.java.mk
will be faster. A quick grep(1) in /usr/ports would detect all of them
and I am pretty sure there are not so many. By that I mean I could
handle it on my own if I had to. That would also be the right time to
check if some Java ports do not use bsd.java.mk yet (v1.0)... But that
could also be checked with portlint IMHO (so that even new ports would
have to use bsd.java.mk).

In my opinion, we could reduce the size (and complexity) of bsd.java.mk
v2.0 by changing something in the "Installed JDK ports detection" stage
by using the JDK port metadata I used in later stages. But that will
make for another release.

That's all for now. Let me know about your opinions.


Regards,

Herve