in bsd.autotools.mk essentially makes this a no-op given that all the
old variables set a USE_AUTOTOOLS_COMPAT variable, which is parsed in
exactly the same way as USE_AUTOTOOLS itself.
Moreover, USE_AUTOTOOLS has already been extensively tested by the GNOME
team -- all GNOME 2.12.x ports use it.
Preliminary documentation can be found at:
http://people.FreeBSD.org/~ade/autotools.txt
which is in the process of being SGMLized before introduction into the
Porters Handbook.
Light blue touch-paper. Run.
[2] Convert to use javavmwrapper (installing to its own PREFIX).
[3] Add to devel category, matching Sun JDKs.
Submitted by: [1] krismail
Reviewed by: [2,3] hq, previous version
sparc64 should be quick, but I haven't been able to scare up the resources on
the cluster machines). Also, remove the compile-time options such as different
AWTs, which are intended by the developers for use in embedded systems, not
general users.
Also, move maintainership to myself, since I'm working on kaffe too frequently.
Thanks Mark for your work on this port!
PR: ports/80641
Submitted by: anholt
Approved by: maintainer
Begin autotools sanitization sequence by requiring ports to explicitly
specify which version of {libtool,autoconf,automake} they need, erasing
the concept of a "system default".
For ports-in-waiting:
USE_LIBTOOL=YES -> USE_LIBTOOL_VER=13
USE_AUTOCONF=YES -> USE_AUTOCONF_VER=213
USE_AUTOMAKE=YES -> USE_AUTOMAKE_VER=14
Ports attempting to use the old style system after June 1st 2004 will be
sorely disappointed.
previous commit message to bsd.port.mk, which said INSTALL_SHLIBS. Boo.)
Line up the rhs of variable assignments nicely. Remove a couple of extra
whitespaces while I'm here.
Suggested by: sobomax
${MACHINE_ARCH}--freebsd${OSREL} is now passed to CONFIGURE_ARGS if
GNU_CONFIGURE is defined. Take the target out of CONFIGURE_ARGS of
some ports that added it explicitly; define it as
${MACHINE_ARCH}--freebsd if the port doesn't like the ${OSREL} part;
define it as something else (such as ${MACHINE_ARCH}--freebsdelf if
the port requires that; define it as an empty string if the port
doesn't like it at all.
The last might be a sign that a GNU_CONFIGURE port actually doesn't
use GNU's version of configure at all; but I don't have time to go
look at them all, we'll fix them as time goes on.
At least we've got much fewer "-unknown-"s in the tree as the result. :)
