Age | Commit message (Collapse) | Author | Files | Lines |
|
by itohy@netbsd.org.
|
|
(approved by jlam).
|
|
ok'd by agc.
|
|
|
|
JVMs from the package-provided PKG_JVM_ACCEPTED list, filter out those
JVMs that aren't available for the current platform. This allows a
package to simply list all JVMs that may be used to build it in
PKG_JVM_ACCEPTED, regardless of platform issues, instead of having to
construct a different PKG_JVM_ACCEPTED based on the platform we are using.
|
|
|
|
platform, and use the intersection of these JVMs and the ones
listed in PKG_JVMS_ACCEPTED as the JVMS that may really be used.
Currently, we assume all of the JVMs are usable by all platforms.
|
|
section that errors out if there is no acceptable JVM found.
|
|
|
|
EVAL_PREFIX is evaluated at the correct time so that the variables it
defines are usable by the CLASSPATH code and the buildlink2 code.
|
|
in bsd.pkg.mk. The java.mk Java handling is largely based on the
lang/python/pyversion.mk file.
There are two new variables:
PKG_JVM_DEFAULT is a user-settable variable whose value is the
default JVM to use.
PKG_JVMS_ACCEPTED is a package-settable list of JVMs that may be
used as possible dependencies for the package.
Two existing variables have been redefined to be only read-only, though
there is some logic to handle legacy /etc/mk.conf which may contain an
explicit PKG_JVM=...
PKG_JVM is a publicly readable variable containing the name of
the JVM we will be using.
PKG_JAVA_HOME is a publicly readable variable containing
${JAVA_HOME} for the PKG_JVM described above.
To do:
Have some way to specify which JVMs are acceptable for each
platform, and use the intersection of these JVMs and the ones
listed in PKG_JVMS_ACCEPTED as the JVMS that may really be used.
Currently, we assume all of the JVMs are usable by all platforms.
I'm not sure if Darwin's special stub sun-{jre,jdk}13 packages
are usable by buildlink2. This needs to be verified.
|
|
JAVA_HOME for that package, so we don't need _JAVA_PREFIX anymore.
|
|
stdout a list of files relative to ${BUILDLINK_PREFIX.<pkg>}. The shell
variable $${pkg_prefix} may be used and is the subdirectory (ending in /)
of ${BUILDLINK_PREFIX.<pkg>} to which the PLIST is relative, e.g. if
`pkg_info -qp foo' returns "/usr/pkg/java/kaffe", then $${pkg_prefix} is
"java/kaffe/".
|
|
Patch from Lubomir Sedlacik in PR 18635.
|
|
too.
|
|
bootstrap-pkgsrc, so adjust accordingly.
Also indent a little better.
|
|
|
|
BUILDLINK_PKGBASE.<pkg> that is the ${PKGBASE} for that package and can
be used as "pkg_info ${BUILDLINK_PKGBASE.<pkg>}". This variable is
currently only used if the buildlink2.mk file uses
BUILDILNK_PLIST_CMD.<pkg> (described below).
* Create readable variable BUILDLINK_PLIST_CMD.<pkg> that is a pipeline of
shell commands that outputs to stdout a list of the files installed the
<pkg>, relative to its installation prefix.
|
|
to be a shell command, e.g.:
BUILDLINK_FILES= `cd ${LOCALBASE}; ${LS} -1 lib/libfoo.*`
|
|
readable through CONFIGURE_ENV and MAKE_ENV. These may be used to fix
up packages that use imake to check the appropriate locations for headers
and libraries.
* Don't be so aggressive in prepending _BLNK_{CPP,LD}FLAGS to
{C,CPP,CXX,LD}FLAGS. The buildlink2 wrapper scripts will automatically
filter out bad -[IL] paths, even if their added inadvertantly by package
Makefiles, so we can simply append them to the existing
{C,CPP,CXX,LD}FLAGS. We try to be smarter about appending them to avoid
needless duplication.
|
|
${CONFIGURE_ENV} and in ${MAKE_ENV} for the configure and build processes,
respectively. This allows overriding the value of "CC" passed to the
build, e.g.:
BUILDLINK_ENV+= CC="/usr/pkg/pthread/bin/pgcc"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
buildlink2.
|
|
creating the buildlink2 wrapper scripts. Based on patch in pkg/18425 by
grant@netbsd.org.
|
|
|
|
wm/sawfish-themes (default: about 180 themes available on themes.freshmeat.net)
|
|
Disables to "no", which results in no gnome-libs being needed.
Patch contributed by Stefan Krüger <skrueger@europe.com> in private mail,
with some changes from me.
|
|
|
|
bar and libbar were swapped).
|
|
|
|
SPECIAL_PERMS are lists that look like:
file user group mode
At post-install time, file (it may be a directory) is changed to be
owned by user:group with mode permissions.
SPECIAL_PERMS should be used primarily to change permissions of files or
directories listed in the PLIST. This may be used to make certain files
set-uid or to change the ownership or a directory.
Packages that install setuid executables should list them in SPECIAL_PERMS
so that the correct user and group will be used for file ownership, even
if the uid/gid changes between the package creation and the package
installation.
|
|
readable way of print messages.
|
|
was only able to check the paths for NetBSD and Linux...Solaris and Darwin
pkgsrc developers should change the path to expr in the right defs.*.mk
file.
|
|
environment. Instead, create a new variable PKG_JAVA_HOME, which is
passed to the configure and build processes via:
JAVA_HOME=${PKG_JAVA_HOME}
to override any environment setting for JAVA_HOME. This should fix
pkg/17989.
|
|
|
|
preference to or in place of Sun audio support in various packages. People
using audio/oss should set USE_OSS in their /etc/mk.conf when building
packages.
|
|
|
|
|
|
|
|
when support for BUILD_DEPEND-only java packages was introduced -- this problem
was preventing java from being registered as a dependency for a number of java-based
packages.
|
|
audio/oss is installed. Also add an example in the comments at the top
of the file that shows how to use the OSS variable.
|
|
the ossaudio emulation to use /dev/sound instead of /dev/audio. For OSS,
DEVOSSSOUND == DEVOSSAUDIO == /dev/dsp.
|
|
OSS instead of the ossaudio OSS emulation library when building software.
|