Ant support in (was [ports-i386@bento ...])

Ant support in (was [ports-i386@bento ...])

Post by herve.quir » Sat, 10 Apr 2004 23:25:01

A PR regarding Ant support in has already been sent some
time ago:

It mostly fixes a bug (ant ignores USE_JAVA settings) but I think we
could build Ant support on top of this.

Previous attempts failed because of complexity. So we should stay
minimalist this time.

That gives:

Variables that a port may define:

- USE_ANT: when set, it means that Ant should be part of the
dependencies of the port.
- ANT_BUILD: when set, it means that Ant should be part of
- ANT_RUN: when set, it means that Ant should be part of RUN_DEPENDS.
- ANT_INCLUDE_SHARED_JARS: when set, it means that JARs from JAVAVARDIR
should be added to the classpath.

Variables/macros provided by in return:

- ANT_CMD: the 'ant' executable
- ANT: the command-line for running Ant. This will setenv JAVA_HOME
according to the JDK set for this port build, and possibly setenv
ANT_INCLUDE_SHARED_JARS=YES according to the Make variable of the same
name (see above).

NOTE: the ANT_BUILD/ANT_RUN variables may seem a bit odd. Actually, they
mimic the JAVA_RUN/JAVA_BUILD from Still we have to be able
to differenciate build and run dependencies. Indeed, although most
applications will use Ant at build stage, some ports (devel/maven for
instance) use Ant to run. Furthermore, devel/maven does not even require
Ant at build stage (it's a binary port). Another method would be:

Variables that a port may define:

- USE_ANT: same as above
- ANT_INCLUDE_SHARED_JARS: same as above

Variable provided by in return:

- ANT_CMD: same as above
- ANT: same as above
- ANT_DEPENDS: the *_DEPENDS value regarding Ant only. This means the
Makefile may contain:




..or even both of these statements.

XXXX@XXXXX.COM mailing list
To unsubscribe, send any mail to " XXXX@XXXXX.COM "

Ant support in (was [ports-i386@bento ...])

Post by glewi » Sun, 11 Apr 2004 08:19:54

n Fri, Apr 09, 2004 at 04:25:10PM +0200, Herve Quiroz wrote:

But ant is a build tool. I don't know of anything that uses it to run.
If we're staying minimalist then maybe this should be left out.

Maybe all we need of these three is USE_ANT which sets a BUILD_DEPENDS
on ant. That will mean the theoretical port that needs ant to run will
have to define an explicit RUN_DEPENDS, but I think that is fine since
I think the number of such ports will approach zero.


Or could just be ANT. There are plenty of utilities which don't have
_CMD in them (e.g. ${MAKE}, which is a close equivalent). Also I think
a number of ports already use ${ANT}, so for them it would be easier to
port. I don't know of any which use ${ANT_CMD}.

How about ${ANT_ENV}, ${ANT} and ${ANT_FLAGS} as per make? Just trying
to stick to something similar for a similar tool :).

Argh, ok, you shot down my comments above by finding a port that uses ant
to run. Thats ok, I can live with that :). However, I think adding a
variable to a central part of the build system for one port isn't a good
option when it forces an extra burden on the other ports which would
have to define ANT_BUILD as well as USE_ANT. I think maven can just do
an explicit RUN_DEPENDS on ant. Are there other ports that use ant at
run time?

No. Just please have add the depends itself, I don't see any
need for it to define the dependency, nor can I think of anything else in
the ports system that does this (although I'm sure you can prove me wrong
again :).

Thats my 2c worth.

Greg Lewis Email : XXXX@XXXXX.COM
Eyes Beyond Web :
Information Technology FreeBSD : XXXX@XXXXX.COM

XXXX@XXXXX.COM mailing list
To unsubscribe, send any mail to " XXXX@XXXXX.COM "