* mk/haskell.mk no longer set USE_TOOLS+=pkg-config for all the packages
that include it. Instead it does TOOLS_FAIL+=pkg-config unless they
explicitly do USE_TOOLS.
* Fixed an issue regarding Template Haskell and our wrappers.
* Fixed an issue where packages that had things like PLIST.common but
lacked PLIST were incorrectly considered to have no PLISTs.
* mk/haskell.mk now supports packages that contain more than a single
library. The INSTALL and DEINSTALL scripts can now handle such packages
properly.
The original FUSE contains a patch version in fuse.pc or fuse3.pc. We must do
the same or otherwise pkg-config requirements such as 'fuse >= 2.6.0' will fail.
Add lua, nodejs, octave, qore, and tk-specific variables. (tk and tk85
define the same variable, so I only included tk.) This relates to
PR pkg/56301, where I noticed various REPLACE_* variables were not
listed in Appendix E of the pkgsrc guide.
There is a separate issue related to Appendix E here. If wip/mk is
found, the auto-generation of the help topic list for the pkgsrc guide
includes anything it finds under that path, but that's potentially
misleading, and causes the generated list to see-saw back and forth as
committers do or do not have wip visible (I do not).
Prune a bunch of variables that haven't been used for years. In some
cases, the packages they influenced don't even exist anymore. There may
be more of these, this is after a quick pass through.
Prior to this change PKGSRC_MKPIE was silently ignored when clang was chosen for
the compiler, i.e. executables were never built as PIE. This became an error
after introducing a post-build check for it.
Of course we should add a MKPIE support for clang, but for now we just emit a
warning. Otherwise we cannot build packages such as devel/gnustep-base which
requires clang to build.
This is needed by packages that require hand-holding in building PIE. Also a
post-build check for MKPIE is performed by default when PKG_DEVELOPER=YES.
resources when fetchers wouldn't be able to save what they download. On
my build farm with pkgsrc (and pkgsrc/distfiles) mounted over NFS,
however, the check gives false positives for NetBSD 9.2 and -current.
Downgrade it to a warning so that these fetches can succeed, while
leaving a breadcrumb in case someone encounters a true positive.
It would of course be interesting to sort out why, in my environment, a
wide variety of other OSes get 1 for "${TEST} ! -w $fetchdir" while
NetBSD gets 0. In the meantime, joerg@ suggested this workaround and
gdt@ agrees it's reasonable to try.
which sets ${PACKAGES} to a subdir of ${PKGSRCDIR}/packages (on the same
NFS mount) so that the generated packages all land in one place.
From my Debian, Devuan, Ubuntu, and CentOS 8 (but not 7) VMs,
copying ${STAGE_PKGFILE} to ${PKGFILE} fails to preserve permissions,
which fails the copy and the "package" target with it. The error
looks like so:
===> Building binary package for foo-4.2
=> Creating binary package /home/schmonz/trees/pkgsrc-cvs/packages/Debian/All/foo-4.2.tgz
/bin/cp: preserving permissions for ‘/home/schmonz/trees/pkgsrc-cvs/packages/Debian/All/foo-4.2.tgz’: Operation not permitted
Assuming permissions on built packages are merely a nice-to-have, avoid
failing if we couldn't preserve them. Patch from sjmulder@, for whom
this fixes a similar problem with FreeBSD with ZFS.
There are only a few releases where this appears to work, and the commit logs
show this to be a complete pain to get working. I've now confirmed it's also
broken on Big Sur where ksh simply segfaults on both x86_64 and arm64.
This may have been marginally useful in the past, but we now have cwrappers to
provide a much bigger performance improvement, and so this hack was only used
during bootstrap to build a small number of packages anyway.
OS_VERSION removes any non-numeric characters, so having a lowercase version
of it will always be identical. There's only a single package, a very old
version of gcc in wip, that references this variable so it should be safe to
just remove and avoid any potential confusion.
Something about NetBSD make(1), at least on 9_STABLE, doesn't like doing this,
resulting in literal "$$3" being passed to awk instead of being escaped down
to "$3". The same construct works fine with pkgsrc bmake(1).
There doesn't appear to be any need to evaluate it inline anyway.
This provides a single integer that can be used in arithmetic expressions
when comparing the current operating system version in make(1).
The two existing variables that are currently used for such tests are
MACHINE_PLATFORM and OS_VERSION. The former usually results in complicated
and hard to read empty() strings, and the latter is often used incorrectly in
version comparisons where developers are unaware that a string comparison is
being performed (for example ".if 5.9 >= 5.10" evaluates to true).
The default based on uname -r should be correct for most systems, and can be
overridden as it is on Darwin where the product version provides a more
useful number than the kernel version.
It's currently impossible to run system binaries inside an arm64 chroot, even
with SIP turned off, so the only way to build is to use an x86_64 chroot and
effectively cross-compile to arm64.
