This allows the user to specify an exact SDK to use, and can be used to build
packages for an older release of macOS than the host. The user should ideally
set this via environment variable at bootstrap time, and pkgsrc will then
encode that into mk.conf and use it for all builds.
Tested on macOS 12.x building against an 11.3 SDK for both arm64 and x86_64.
HASKELL_ENABLE_SHARED_LIBRARY, HASKELL_ENABLE_LIBRARY_PROFILING, and
HASKELL_ENABLE_HADDOCK_DOCUMENTATION are user-settable variables that can
affect the set of installed files. `make print-PLIST' should automatically
handle these.
It's a list of Cabal package names whose version constraints need to be
relaxed. This should free ourselves from needing to patch *.cabal files
most of the time. Suggested by wiz@
Most systems use GNU ld, which will happily pull in symbols required by a
program even if they are only available via implicit library dependencies. The
SunOS linker is stricter, and if a program uses a symbol then the library that
defines that symbol must be an explicit dependency.
This mostly causes problems with libiconv and libintl, both of which Linux
bundles in its C library, so a lot of third-party software does not correctly
check for them. Until now we've had to add many, many overrides, along with
variables such as BROKEN_GETTEXT_DETECTION which nowadays only has limited
effectiveness.
The situation appears to be getting worse, especially with software built with
meson, and so both libiconv and gettext-lib will now automatically add the
correct LDFLAGS if the OPSYS sets OPSYS_EXPLICIT_LIBDEPS=yes.
This isn't perfect. For one it isn't really an OPSYS setting as you can try to
use GNU ld on SunOS, it just doesn't work very well. It should also really be
done via the wrappers rather than exposing LDFLAGS, but we do not yet have an
approved patch for doing this. However it does improve the current situation.
unintended consequences when an older userland is bootstrapped, and
incompatibility with osabi. Separate variable for userland version
for NetBSD is likely the way forward.
on NetBSD, rather than the kernel version. Should resolve building
packages with workarounds for -9 on a -9 userland and CURRENT kernel.
Thanks to Hauke Fath for the hint.
As recently discussed on tech-pkg, this should be considered "Free or
Open Source", so add it accordingly. Probably this was never done
before just because it is so uncommon.
Debian allows inclusion of it as such (e.g., it's one of the
attributions they note applies to OpenSSH code in their packaging of
it), as do other mainstream Linux distros like Fedora.
Debian package review where this is stated:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685575
Fedora policy:
https://fedoraproject.org/wiki/Licensing/Beerware
This makes the library chosen appear in all places it's supposed to in
the buildlink tree instead of just the first time it's mentioned.
Closes PR 47017 (mk/jpeg.bl3.mk is order-dependent)
The expressions for USE_BUILTIN.* and for IGNORE_PKG.* can be undefined.
The function 'empty' takes care of these, the direct expressions
generate a (misleading) error message 'Malformed conditional'.
pkgsrc does not support NetBSD 5 anymore.
Back then, when expanding the body of a .for loop, the variable values
were inserted verbatim in the body, allowing for lots of unintended
special effects, making it essentially impossible to use these values
directly in conditions.
In this case, the values do not contain double quotes, that's why
enclosing the ${_pkg_} in double quotes worked.
See src/usr.bin/make/unit-tests/directive-for.mk for more details,
search for '2008-12-21'.
Combining .for loops with 'empty(...)' conditions still does not work,
so replace these with direct comparisons. Before 2008-12-21, using
'empty(...)' was the safer variant because it avoided the uncontrolled
code injection.
No functional change.
For now the GCC "c99 == gnu99" override is kept, but gnu99 is now supported as
a specific value for USE_LANGUAGES, so we may want to be specific where
required.
c11 and c17 (and the corresponding gnu11/gnu17 versions) are newly supported.
