From owner-freebsd-java@FreeBSD.ORG Thu Aug 21 08:56:00 2003 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67FA816A4BF for ; Thu, 21 Aug 2003 08:56:00 -0700 (PDT) Received: from puget.esil.univ-mrs.fr (puget.esil.univ-mrs.fr [139.124.41.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13BC143FF2 for ; Thu, 21 Aug 2003 08:55:59 -0700 (PDT) (envelope-from herve.quiroz@esil.univ-mrs.fr) Received: from puget.esil.univ-mrs.fr (localhost.esil.univ-mrs.fr [127.0.0.1]) h7LFutFE034517; Thu, 21 Aug 2003 17:56:55 +0200 (CEST) (envelope-from herve.quiroz@esil.univ-mrs.fr) Received: from localhost (rv@localhost)h7LFurtb034514; Thu, 21 Aug 2003 17:56:53 +0200 (CEST) X-Authentication-Warning: puget.esil.univ-mrs.fr: rv owned process doing -bs Date: Thu, 21 Aug 2003 17:56:53 +0200 (CEST) From: Herve Quiroz X-X-Sender: rv@puget.esil.univ-mrs.fr To: Herve Quiroz In-Reply-To: <20030820195123.W11521@puget.esil.univ-mrs.fr> Message-ID: <20030821151753.R32852@puget.esil.univ-mrs.fr> References: <20030514.125107.74756915.haro@kgt.co.jp> <20030818154837.P56591@puget.esil.univ-mrs.fr> <20030820195123.W11521@puget.esil.univ-mrs.fr> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-441575913-1061481413=:32852" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: Greg Lewis cc: freebsd-java@freebsd.org Subject: Re: bsd.java.mk 2.0 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 15:56:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-441575913-1061481413=:32852 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. 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. 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 --0-441575913-1061481413=:32852--