Fixes builds inside an x86_64 chroot where packages add x86-specific flags
based on the output of uname even though we're building for aarch64. CMake
provides the CMAKE_APPLE_SILICON_PROCESSOR variable for this situation.
The rewritten check for unknown configure options already checks for
options that are not defined anywhere. After that, the configure scripts
don't need to check for these options anymore since all remaining options
are known to the package, in at least one of its configure scripts.
The previous implementation could not reliably detect outdated configure
options. This was apparent in devel/gettext-tools, where the option
--with-included-libcroco had become unknown between May 2019 and May
2020, but the check was not run.
The behavior is the same in the pkgsrc default configuration. Only if
GNU_CONFIGURE_STRICT=yes, the new check is activated and will make
packages fail that previously succeeded to build. Since that variable is
not widely known, there won't be much sudden breakage, if any.
There are several places in pkgsrc where the files to be patched are
listed individually instead of just saying util/*/*.sh. This is
unnecessarily detailed. Encourage package authors to use filename
patterns more often.
An example is REPLACE_PYTHON in lang/clang, which currently fails because
some of the listed files don't exist anymore.
This allows easy inspection of the realistic environment in which the
configure scripts are run.
The code is copied from the similar build-env target.
This might help to find the cause for pkg/54894, where "gcc -dumpversion"
is said to output 0 as the version number.
When "bmake clean depends" was called for a package where the various
cookie files already existed, these would enable different rules than a
clean package directory.
Since "bmake clean" deletes all the cookie files before "bmake depends"
starts, in these combined command lines the cookie files must be treated
as absent.
This helps to find out which of the several configure scripts has
problems, for example when checking for unknown command line options
using GNU_CONFIGURE_STRICT.
When a Makefile fragment contains $0, this means a Makefile variable, not
a shell or AWK variable.
The bug in ccc.mk survived unnoticed for almost 15 years. The bug in
gnu-configure.mk for MirBSD got only half as old.
When a GNU configure script is run with unknown --enable, --disable,
--with or --without options, it doesn't fail but just prints a warning.
This hides outdated package definitions that may still pass options that
have been removed already.
See https://mail-index.netbsd.org/pkgsrc-users/2019/04/02/msg028272.html
for a recent case.
The default behavior doesn't change. After a period of testing this new
check, the check is expected to become enabled by default so that future
problems like this are prevented.
Up to now, there was a central list of variable name patterns that
defined whether a variable was printed as a sorted list, as a list or as
a single value.
Now each variable group decides on its own which of the variables are
printed in which way, using the usual glob patterns. This is more
flexible since different files sometimes differ in their naming
conventions.
Two variable groups are added: license (for everything related to
LICENSE) and go (for lang/go).
CMAKE_PKGSRC_BUILD_FLAGS
If set to yes, disable compiler optimization flags associated
with the CMAKE_BUILD_TYPE setting (for pkgsrc these come in from
the user via variables like CFLAGS). The default is yes, but you can
set it to no for pkgsrc packages that do not use a compiler to avoid
cmake "Manually-specified variables were not used by the project"
warnings associated with this variable.
Changes since 2.4.2 are too numerous to mention, with over 4,700 lines
in the ChangeLog file. However, this release does at least fix a large
number of build failures on SmartOS, and doesn't appear to cause any
obvious regressions in bulk builds performed by Joerg and myself.
Some pkgsrc cleanups while here, including merging the MirBSD patches
correctly. It couldn't be made much clearer how to properly integrate
patches here to ensure they are not lost. Next time you might not be so
fortunate!
By default CMAKE_INSTALL_PREFIX points to PREFIX, but some software requres
custom subprefix. At least blender and brlcad are in this category.
To set new prefix it's sufficient to set CMAKE_INSTALL_PREFIX in a package,
for example (in brlcad):
CMAKE_INSTALL_PREFIX=${PREFIX}/brlcad
Reviewed by <joerg> and <jperkin>.
conflict with pkgsrc versions of those packages, and do not interact well
with the wrappers anyway as cmake will perform simple file-based tests for
headers but the compiler will be unable to find them.
overrides for libtool. This allows us to easily get the fixed version
from our libtool in place without having to hunt down for the specific
bugs in random places. Disable the override explicitly in clisp, which
installs a copy without explicitly depending on libtool at run time.
wrapped version by full path. This fixes some cases where the wrappers
have been bypassed. lang/lua52 triggered the investigation as it failed
to link against libreadline, which should have been translated to
libedit. Tested by jperkin and myself with full bulk builds.
--libdir handling, same as for --mandir and --infodir.
Currently, HAS_CONFIGURE_LIBDIR=no by default unless libdir related variables
are set, but it will be switched to "yes" after all packages have been checked
(and SET_LIBDIR will be deprecated).
This file is from libtool-1.x, which is not in pkgsrc any longer
(using libtool-2.x since 2009). Also, it was only used for packages
using autoconf-2.13 AND libtool; I found three packages in pkgsrc with
that combination, and all of them still build on NetBSD-6.99.24/amd64
after this change.
