Date: Fri, 23 May 2003 01:28:54 -0600 From: Greg Lewis <glewis@misty.eyesbeyond.com> To: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr> Cc: freebsd-java@FreeBSD.org Subject: Re: bsd.java.mk 2.0 Message-ID: <20030523072854.GA61661@misty.eyesbeyond.com> In-Reply-To: <20030521145031.Q14339@puget.esil.univ-mrs.fr> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030523072854.GA61661>