From owner-freebsd-java@FreeBSD.ORG Fri May 23 00:33:36 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 91B6237B404 for ; Fri, 23 May 2003 00:33:36 -0700 (PDT) Received: from mgr3.xmission.com (mgr3.xmission.com [198.60.22.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3608A43FBD for ; Fri, 23 May 2003 00:33:35 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: from mail by mgr3.xmission.com with spam-scanned (Exim 3.35 #1) id 19J73V-0004iz-03 for freebsd-java@freebsd.org; Fri, 23 May 2003 01:33:34 -0600 Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr3.xmission.com with esmtp (Exim 3.35 #1) id 19J723-0003ub-03; Fri, 23 May 2003 01:33:08 -0600 Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.12.9/8.12.9) with ESMTP id h4N7W4MP061741; Fri, 23 May 2003 01:35:03 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.12.9/8.12.9/Submit) id h4N7TIB7061730; Fri, 23 May 2003 01:29:18 -0600 (MDT) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Fri, 23 May 2003 01:28:54 -0600 From: Greg Lewis To: Herve Quiroz Message-ID: <20030523072854.GA61661@misty.eyesbeyond.com> References: <20030514.125107.74756915.haro@kgt.co.jp> <20030515212719.GA18091@misty.eyesbeyond.com> <20030520181421.GB28600@misty.eyesbeyond.com> <20030521145031.Q14339@puget.esil.univ-mrs.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030521145031.Q14339@puget.esil.univ-mrs.fr> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-9.9 required=8.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT,X_AUTH_WARNING version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) 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: Fri, 23 May 2003 07:33:36 -0000 Hi Herve, On Wed, May 21, 2003 at 03:04:57PM +0200, Herve Quiroz wrote: > On Tue, 20 May 2003, Greg Lewis wrote: > > > First there are two variable called NO_BUILD_DEPENDS and NO_RUN_DEPENDS. I > > > propose we only use one: USE_JAVA= [run | build | both] > > > > I'm not sure we need "both" since if you need a JDK to build a port then > > presumably that port contains some Java code that needs to run. As an > > alternative suggestion I would propose: > > > > USE_JAVA = [ jre | jdk ] > > > > Where "jre" indicates that we just need a RUN_DEPENDS which can be satisfied > > by a JRE (or JDK). The "jdk" value would indicate a BUILD_DEPENDS on a > > JDK with a RUN_DEPENDS on a JRE (or JDK). > > > > This may need extending to cope with ports that need a JDK at run time > > (any examples?). > > devel/jakarta-ant ? Good call. How about: USE_JAVA = [ BUILD-RUN ] Where BUILD and RUN may take the values jdk or jre. I think this should be clear, but the BUILD portion adds a build depends and the RUN portion adds a run depends. The most common case will be jdk-jre, meaning the port requires the JDK to build but only the jre to run. This kinda feels a little clunky, so as an alternative maybe: USE_JAVA = yes JAVA_BUILD = jdk JAVA_RUN = jre Comments? > > We're obviously breaking backward compatibility here, but I think thats > > pretty much unavoidable to get the features we want. > > I agree... What is the policy regarding such major changes in ports ? I > mean it will make a lot of ports deprecated and broken. So we should > provide bsd.java.mk 2.0 together with all Java ports patches IMHO. The policy is that we do a sweep and fix the ports when we switch over to the new bsd.java.mk. Actually, the policy is we do the sweep before hand and verify all work with the new bsd.java.mk and then just commit the changes when we commit the new bsd.java.mk. > > USE_JAVA_VERSION = 1.1 - 1.3 > > > > which is something I'd like the next version to be able to cope with. > > > > There also doesn't seem to be a way to prefer one version over the other, > > which is another thing I'd like to see. For example, a port may build > > and work with 1.2, but may provide more functionality if built and run > > with 1.3. In that case, how do I specify 1.2+ but with a preference for > > using 1.3 if its available? > > > > > Each of which may be empty or undefined if the choice is not important. > > > USE_JAVA_VENDOR may contain a list of vendors. > > > > Space separated? Are they in order of preference? If so maybe we can > > do the same with USE_JAVA_VERSION and USE_JAVA_OS to satisfy my > > > > preference example above, e.g. > > > > USE_JAVA_VERSION = 1.3 1.2 > > I think we've got something here: use space separated preferences (in the > right order) for all JDK/JRE properties. So no more "+" (e.g. "1.3+") but > instead an explicit list of versions... I like the space separation :). However, I think the "+" sign is still useful as a short hand for 1.x 1.y ... 1.current. It also means we don't have to do a sweep when a new Java version comes out and add (for example) 1.5 to the list. I think for maximum flexibility and to preserve the usefulness of the "+" we should allow both a "+" and a space separated list. If the version is written with a "+" it must be the only version, i.e. you can't have "1.1 1.3+" as a list. > > I would also suggest that USE_JAVA_{VENDOR,VERSION,OS,PORT} become simply > > JAVA_{VENDOR,VERSION,OS,PORT} as that is more in line with the other > > language makefiles (e.g. bsd.python.mk). > > You're right. > > Looks like we're progressing with bsd.java.mk... Any feedback from other > Java porters ? Yes, please jump in if you have an idea to add to the melting pot. Now is the time! -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org