NFCI on non-macOS or macOS with working /usr/bin/{m4,yacc}.
FCI on macOS with Command Line Tools 15.3.0.0.1.1708646388: packages
that don't properly declare m4 or yacc in USE_TOOLS will now silently
invoke no-op versions of those tools, rather than popping up the useless
CLT install dialog.
Post-freeze, we can consider switching to TOOLS_FAIL and/or generalizing
an optional mode in which invoking any undeclared tool on any platform
breaks the build.
xcrun lately seems to include PATH in its search, which means programs
that aren't part of Apple's developer tools get matched:
:; xcrun --find mutt
/opt/pkg/bin/mutt
xcrun also has a cache, so this can produce even odder results:
:; xcrun --find yacc
/opt/pkg/bin/yacc
:; env - xcrun --find yacc
/opt/pkg/bin/yacc
:; xcrun --no-cache --find yacc
/opt/pkg/bin/yacc
:; env - xcrun --no-cache --find yacc
xcrun: error: unable to find utility "yacc", not a developer tool or in PATH
Since xcrun has had the "--no-cache" argument dating back to at least
the days of OS X 10.6.8 with gcc 4.2.1 and Apple clang 1.7, add it to
"xcrun --find" commands (along with an empty PATH) for more
deterministic results.
There is an existing rule that translates c++03 to c++0x for old
versions of GCC - this is iffy, GCC treats c++0x as an alias for c++11.
Rewrite c++03 to c++98 for older compilers instead.
As soon as 2024Q1 branches, we should:
1. Do a bulk build with all these -Wno-error tweaks removed, so we can
see how much is broken.
2. If it's "too much" breakage and we'll have to keep overriding these
compiler defaults for "a while", find a way to accomplish them with
fewer compiler invocations. (Some ideas: define a default
FORCE_C_STD, or apply overrides keyed on CC_VERSION or similar.) Do
a bulk build to make sure things continue to work as before.
3. Otherwise, fix as much as we can before 2024Q2. This will help with
gcc 14 (which has many similar new defaults) as well.
CLT 15.3.0.0.1.1708646388 does not provide m4 or yacc. For these two
tools, don't default TOOLS_PLATFORM.foo to "/usr/bin/foo" unless the
backing CLT-provided foo binary is found. This lets the tools framework
fall back to something else, as intended.
Perhaps this was required in some ancient version of curl, but in any modern
version having both "-o filename" and "-O" (which means to use the remote
filename) only results in "Warning: Got more output options than URLs" messages
for every single download.
Either
if ((q = strchr(p, '/')) == NULL)
or
if (*(q = strchrnul(p, '/')) == '\0')
will work, but not
if (*(q = strchr(p, '/')) == '\0')
which will crash with a null pointer dereference. Let's get the
right version of this committed, not the wrong one! Oops.
While here, reset PKGREVISION like I meant to do yesterday.
This puts it before defaults/mk.conf, which has no effect here --
there's no default TARGET_ARCH, MAKEOBJDIR, or CROSS_DESTDIR in
defaults/mk.conf, and defaults/mk.conf is not affected by
MACHINE_ARCH (immediately, anyway), CROSS_DESTDIR, or _CROSS_DESTDIR.
Later we'll add more variables like MACHINE_ARCH here affected by a
TARGET_* variable, including OBJECT_FMT. This will allow us to
handle OBJECT_FMT via TARGET_OBJECT_FMT before the next stanza which
provides OPSYS-based defaults for OBJECT_FMT.
No change for native builds since this only moves around a block
gated on USE_CROSS_COMPILE = yes.
This way it can be handled by the cross variable logic when the host
and target have misatched object formats, like building NetBSD
packages (ELF) on macOS (Mach-O).
This whole stanza can be removed when PR pkg/57837
(bootstrap-mk-files bsd.own.mk defines wrong OBJECT_FMT on macOS
(Darwin), https://gnats.NetBSD.org/57837) is fixed.
No functional change intended so far -- this just makes subsequent
patches easier to follow.
The files in ERROR_DIR must not start with a dot, or they are simply
ignored.
No change in the default configuration, since CHECK_FILES_STRICT
defaults to no.
In 2008, when ${_PKG_SILENT}${_PKG_DEBUG} was replaced with the shorter
${RUN}, the backslashes were accidentally moved away from their
canonical position.
In the :C modifiers, there is no reason to use '/' as delimiter when the
search pattern or the replacement contains a literal '/' as well, which
then has to be escaped as '\/'.
While here, add two more variables to show-all-check-files, as pkglint
started warning about them.
Previously, building a package that had the wrong number of words in
MAKE_DIRS_PERMS failed with "can't shift that many", which didn't give a
hint at the underlying problem. Now it fails immediately, pointing to
the line in check-files.mk that loops over MAKE_DIRS_PERMS and
OWN_DIRS_PERMS.
These are always about the target system, which during cross builds,
or native builds of cross-libtool-base, is relative to
TOOLS_CROSS_DESTDIR.
This is necessary for cross-libtool-base -- the one special package
that is built as a native package as if it were cross-compiled, so
_CROSS_DESTDIR is empty but TOOLS_CROSS_DESTDIR is the cross destdir
-- because cross-libtool-base uses buildlink3 and dlopen.builtin.mk.
No change to native builds because _CROSS_DESTDIR and
TOOLS_CROSS_DESTDIR are both empty in native builds.
XXX Perhaps almost every use of _CROSS_DESTDIR outside mk/pkgformat
should be replaced by TOOLS_CROSS_DESTDIR.
- If we're cross-compiling or building cross-libtool-base, alias for
CROSS_DESTDIR.
- Otherwise, empty.
This will be convenient for sprinkling TOOLS_CROSS_DESTDIR in various
places throughout mk/ without worrying about disrupting native
builds.
No change to native builds here because all current references are
conditional on USE_CROSS_COMPILE = yes.
This is executed at build-time, not baked into the target package to
execute at run-time, so we need the native pkg_info command that can
be executed at build-time.
No change to native builds, where NATIVE_PKG_INFO_CMD is the same as
PKG_INFO_CMD.
(PKG_INFO, used above in _BLNK_PKG_DBDIR.${_pkg_}, is already defined
in terms of NATIVE_PKG_INFO_CMD, so no need to change anything for
_BLNK_PKG_DBDIR.${_pkg_}.)
This is a command to be run in the target system, so it doesn't work
to run it at build-time, which might be a different architecture and
operating system altogether giving unrelated answers.
No change to native builds because this just makes some existing
logic conditional on native builds.
gdt
schmonz
nia
wiz
jperkin
adam
riastradh
taca
rillig
jnemeth
gutteridge