Date: Fri, 23 May 2003 14:31:29 +0200 (CEST) From: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr> To: Greg Lewis <glewis@misty.eyesbeyond.com> Cc: freebsd-java@FreeBSD.org Subject: Re: bsd.java.mk 2.0 Message-ID: <20030523140852.H81713@puget.esil.univ-mrs.fr> In-Reply-To: <20030523072854.GA61661@misty.eyesbeyond.com> References: <20030514.125107.74756915.haro@kgt.co.jp> <20030520181421.GB28600@misty.eyesbeyond.com> <20030523072854.GA61661@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Greg, On Fri, 23 May 2003, Greg Lewis wrote: > > > 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? At first, I would have said I prefer the second. But I don't know really. Maybe with an example I can figure what you mean exactly. Tell me f I understand correctly: For most of the ports (libs): USE_JAVA= BUILD=jdk RUN=jre Which means build dependency for the chosen JDK and run dependency for the chosen JRE For devel/jakarta-ant: USE_JAVA= RUN=JDK Which means it builds without anything (JDK related I mean) as ant is "install only" and need a JDK to run. > > > 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. That's ok. A lot of work at once but Java ports are not updated too often anyway. > > 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. That's a good point. The "+" is still greatly needed. And may be overriden by the bsd.java.mk: .if ${USE_JAVA_VERSION} == "1.3+" USE_JAVA_VERSION= 1.3 1.2 1.1 .endif So we need to update only bsd.java.mk when a new version of Java comes out. BTW, I know this is a bit off-topic but I would like to emphasize the fact that all those JDK/JRE port dependency handling would greatly benefit from XML. Because specifying a set of possible JDK using XPath would really be simple. Then again, it would break the Make stuff and, as Jan Grant told us, XML is not (yet?) seen as a viable alternative to the current scheme. But just my cents on the subject: With a java-ports.xml referencing all JDK ports, aproximatively the same way Ernst described it in his PR. Then in the port's Makefile you specify: USE_JAVA= run="//jdk[@version > 1.3 and @vendor == 'sun']" Then bsd.java.mk performs XSLT ro produce a nice, clean Makefile (but that's a bit too "hardcoded" IMHO). Or else, it could just get the name of the right JDK by using some command-line XPath query tool. BTW, I am currently working on such a tool with limited lib dependencies. Et voila ! Note: the java-ports.xml could benefit from XInclude so each JDK porter just need to provide an XML file to describe the JDK he maintains. Note(2): Again this is just off-topic, "free-style" thoughts on the subject. And this should probably stay as-is. :) > > 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! Ernst told me he hasn't had time to read from this mailing list these last days. Still I would like to hear his opinions on the topic. Mostly because he is the maintainer of bsd.java.mk and also because he is the maintainer of a number of Java ports. Regards, Herve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030523140852.H81713>