d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a2bc17474b
freebsd-skq/share/mk/bsd.opts.mk

135 lines
3.8 KiB
Makefile
Raw Normal View History

Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
# $FreeBSD$
#
# Option file for src builds.
#
# Users define WITH_FOO and WITHOUT_FOO on the command line or in /etc/src.conf
# and /etc/make.conf files. These translate in the build system to MK_FOO={yes,no}
Some minor doc fixups - Tweak a sentence by placing the modifier before an adjective to make it flow better. - Fix a typo. MFC after: 3 days
2017-08-02 21:31:46 +00:00
# with (usually) sensible defaults.
Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
#
# Makefiles must include bsd.opts.mk after defining specific MK_FOO options that
# are applicable for that Makefile (typically there are none, but sometimes there
# are exceptions). Recursive makes usually add MK_FOO=no for options that they wish
# to omit from that make.
#
Fix typo in comments. Noticed by: brooks@
2014-12-12 18:54:31 +00:00
# Makefiles must include bsd.mkopt.mk before they test the value of any MK_FOO
Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
# variable.
#
# Makefiles may also assume that this file is included by bsd.own.mk should it
# need variables defined there prior to the end of the Makefile where
# bsd.{subdir,lib.bin}.mk is traditionally included.
#
# The old-style YES_FOO and NO_FOO are being phased out. No new instances of them
# should be added. Old instances should be removed since they were just to
# bridge the gap between FreeBSD 4 and FreeBSD 5.
#
# Makefiles should never test WITH_FOO or WITHOUT_FOO directly (although an
# exception is made for _WITHOUT_SRCONF which turns off this mechanism
# completely).
#
.if !target(__<bsd.opts.mk>__)
__<bsd.opts.mk>__:
.if !defined(_WITHOUT_SRCCONF)
#
# Define MK_* variables (which are either "yes" or "no") for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
# make(1) environment.
# These should be tested with `== "no"' or `!= "no"' in makefiles.
# The NO_* variables should only be set by makefiles for variables
# that haven't been converted over.
#
Better documentation for why KERBEROS and OPENSSH are here, and where to look for all the other options that used to be here (well, in bsd.own.mk) Suggested by: des@
2014-05-27 16:30:54 +00:00
# Only these options are used by bsd.*.mk. KERBEROS and OPENSSH are
Some minor doc fixups - Tweak a sentence by placing the modifier before an adjective to make it flow better. - Fix a typo. MFC after: 3 days
2017-08-02 21:31:46 +00:00
# unfortunately needed to support statically linking the entire
Better documentation for why KERBEROS and OPENSSH are here, and where to look for all the other options that used to be here (well, in bsd.own.mk) Suggested by: des@
2014-05-27 16:30:54 +00:00
# tree. su(1) wouldn't link since it depends on PAM which depends on
# ssh libraries when building with OPENSSH, and likewise for KERBEROS.
# All other variables used to build /usr/src live in src.opts.mk
# and variables from both files are documented in src.conf(5).
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
__DEFAULT_YES_OPTIONS = \
ASSERT_DEBUG \
Build and install userland .debug files by default Debug data files are now built by default with 'make buildworld' and installed with 'make installworld'. This facilitates debugging but requires more disk space both during the build and for the installed world. Debug files may be disabled by setting WITHOUT_DEBUG_FILES=yes in src.conf(5). Reviewed by: bdrewery, eadler, vangyzen Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D4018
2015-12-07 19:15:52 +00:00
DEBUG_FILES \
Move DOCCOMPRESS to MK variable.
2014-05-10 16:38:54 +00:00
DOCCOMPRESS \
Acutally, replaces NO_INCS with WITHOUT_INCLUDES and make WITHOUT_TOOLCHAIN imply it instead. Sponsored by: Netflix
2014-11-18 17:06:44 +00:00
INCLUDES \
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
INSTALLLIB \
KERBEROS \
Add limited sandbox capability to "make check" == Rationale == r295380 introduced "make check" and consolidated means for running test code in an attempt to simplify running tests. One could either install files/libraries/programs and run "make check", or run "make check" with an explicit CHECKDIR, e.g., `make check CHECKDIR=$(make -V.OBJDIR)``. One criticism that was received is that "make check" should be run with the intent of making dev->test->commit easier, which means that the target audience's workflow should be developers. One developer pattern available in other opensource projects is to run test code from a developer sandbox, instead of installing to a system. == Method == This approach is slightly different from the standard approach, in the sense that it builds and installs into a deterministic directory under .OBJDIR (as I call it, the "sandbox"), then runs "make check" against that. In the event the test run is successful, the deterministic directory is removed to save space. == Approach == bsd.lib.mk, bsd.prog.mk: To support this functionality, a new variable `HAS_TESTS` is being added. HAS_TESTS enables appropriate behavior with bsd.lib.mk and bsd.prog.mk, as follows: - Add "make check" as an available target from the directory. - Pass down appropriate variables via ${TESTS_ENV}, i.e., ${TESTS_LD_LIBRARY_PATH} and ${TESTS_PATH}. One should add "HAS_TESTS" to directories containing tests in them, e.g. from bin/sh/Makefile, HAS_TESTS= SUBDIR.${MK_TESTS}+= tests HAS_TESTS doesn't automatically add the tests subdirectory for flexibility reasons. bsd.opts.mk, src.opts.mk: - The knob ${MK_MAKE_CHECK_USE_SANDBOX} has been added, both to explicitly direct (internally) when to set a deterministic ${DESTDIR} and to also allow users to disable this behavior globally, i.e., via src.conf. - MK_TESTS has been promoted from src.opts.mk to bsd.opts.mk to leverage syntactic sugar for having MK_TESTS be a dependency for MK_MAKE_CHECK_USE_SANDBOX, but to also ensure that src.opts.mk isn't required to use suite.test.mk (which is a dependency of bsd.test.mk). suite.test.mk: - beforecheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Build. -- Run "make hierarchy" on the sandbox dir. -- Install the tests/files to the sandbox dir. - aftercheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Remove the sandbox dir. Again, because the dependency order set in bsd.test.mk is beforecheck -> check -> aftercheck, "make check" will not be run unless "beforecheck" completes successfully, and "aftercheck" will not be run unless "beforecheck" and "check" complete successfully. == Caveats == - This target must either be run with MK_INSTALL_AS_USER or as root. Otherwise it will fail when running "make install" as the default user/group for many makefiles when calling INSTALL is root/wheel. - This target must be run from a suitable top-level directory. For example, running tests from `tests/sys/fs/tmpfs` won't work, but `tests/sys/fs` will, because `tests/sys/fs/tmpfs` relies on files installed by `tests/sys/fs`. - Running MK_INSTALL_AS_USER may introduce determinism issues. However, using it could identify deficiences in tests in terms of needing to be run as root, which are not properly articulated in the test requirements. - The doesn't negate the need for running "make installworld" and "make checkworld", etc. Again, this just is intended to simplify the dev->test->commit workflow. == Cleanup done == - CHECKDIR is removed; one can use "MK_MAKE_CHECK_USE_SANDBOX=no" to enable "legacy" (r295380) behavior. MFC after: 2 months Relnotes: yes (CHECKDIR removed; "make check" behavior changed) Requested by: jhb Reviewed by: arch (silence), testing (silence) Differential Revision: D11905
2017-08-14 19:03:05 +00:00
MAKE_CHECK_USE_SANDBOX \
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
MAN \
MANCOMPRESS \
NIS \
NLS is used by the build system.
2014-04-29 14:52:39 +00:00
NLS \
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
OPENSSH \
PROFILE \
SSP \
Add limited sandbox capability to "make check" == Rationale == r295380 introduced "make check" and consolidated means for running test code in an attempt to simplify running tests. One could either install files/libraries/programs and run "make check", or run "make check" with an explicit CHECKDIR, e.g., `make check CHECKDIR=$(make -V.OBJDIR)``. One criticism that was received is that "make check" should be run with the intent of making dev->test->commit easier, which means that the target audience's workflow should be developers. One developer pattern available in other opensource projects is to run test code from a developer sandbox, instead of installing to a system. == Method == This approach is slightly different from the standard approach, in the sense that it builds and installs into a deterministic directory under .OBJDIR (as I call it, the "sandbox"), then runs "make check" against that. In the event the test run is successful, the deterministic directory is removed to save space. == Approach == bsd.lib.mk, bsd.prog.mk: To support this functionality, a new variable `HAS_TESTS` is being added. HAS_TESTS enables appropriate behavior with bsd.lib.mk and bsd.prog.mk, as follows: - Add "make check" as an available target from the directory. - Pass down appropriate variables via ${TESTS_ENV}, i.e., ${TESTS_LD_LIBRARY_PATH} and ${TESTS_PATH}. One should add "HAS_TESTS" to directories containing tests in them, e.g. from bin/sh/Makefile, HAS_TESTS= SUBDIR.${MK_TESTS}+= tests HAS_TESTS doesn't automatically add the tests subdirectory for flexibility reasons. bsd.opts.mk, src.opts.mk: - The knob ${MK_MAKE_CHECK_USE_SANDBOX} has been added, both to explicitly direct (internally) when to set a deterministic ${DESTDIR} and to also allow users to disable this behavior globally, i.e., via src.conf. - MK_TESTS has been promoted from src.opts.mk to bsd.opts.mk to leverage syntactic sugar for having MK_TESTS be a dependency for MK_MAKE_CHECK_USE_SANDBOX, but to also ensure that src.opts.mk isn't required to use suite.test.mk (which is a dependency of bsd.test.mk). suite.test.mk: - beforecheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Build. -- Run "make hierarchy" on the sandbox dir. -- Install the tests/files to the sandbox dir. - aftercheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Remove the sandbox dir. Again, because the dependency order set in bsd.test.mk is beforecheck -> check -> aftercheck, "make check" will not be run unless "beforecheck" completes successfully, and "aftercheck" will not be run unless "beforecheck" and "check" complete successfully. == Caveats == - This target must either be run with MK_INSTALL_AS_USER or as root. Otherwise it will fail when running "make install" as the default user/group for many makefiles when calling INSTALL is root/wheel. - This target must be run from a suitable top-level directory. For example, running tests from `tests/sys/fs/tmpfs` won't work, but `tests/sys/fs` will, because `tests/sys/fs/tmpfs` relies on files installed by `tests/sys/fs`. - Running MK_INSTALL_AS_USER may introduce determinism issues. However, using it could identify deficiences in tests in terms of needing to be run as root, which are not properly articulated in the test requirements. - The doesn't negate the need for running "make installworld" and "make checkworld", etc. Again, this just is intended to simplify the dev->test->commit workflow. == Cleanup done == - CHECKDIR is removed; one can use "MK_MAKE_CHECK_USE_SANDBOX=no" to enable "legacy" (r295380) behavior. MFC after: 2 months Relnotes: yes (CHECKDIR removed; "make check" behavior changed) Requested by: jhb Reviewed by: arch (silence), testing (silence) Differential Revision: D11905
2017-08-14 19:03:05 +00:00
TESTS \
Migrate NO_WARN to MK_WARN. Support legacy NO_WARN usage. Remove a check for EARLY_BUILD because it isn't necessary (MK_WARN=no will always be defined for that).
2014-05-10 16:37:53 +00:00
TOOLCHAIN \
Rename NO_WERROR -> MK_WERROR=no As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses. Reviewed By: brooks Differential Revision: https://reviews.freebsd.org/D27601
2021-01-06 17:55:06 +00:00
WARNS \
WERROR
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
__DEFAULT_NO_OPTIONS = \
Add a WITH_BIND_NOW build knob The linker's -z now flag sets the DF_BIND_NOW flag, which signals to the runtime loader that all relocation processing should be performed at process startup rather than on demand. In combination with lld's default of enabling relro this causes the GOT to be made read-only when the process starts, preventing straightforward GOT overwrite attacks. Shawn Webb discovered a failure on HardenedBSD with BIND_NOW and ifunc use, which resulted in my rtld fix in r340137. Add a BIND_NOW knob as it is trivial to do so and is a useful ELF hardening feature. This change is equivalent to HardenedBSD's but not identical as there are other diffs/conflicts nearby. Note that our ELF Tool Chain readelf does not currently decode the DF_BIND_NOW flag - see PR232983. Reviewed by: brooks MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17846
2018-11-06 15:52:49 +00:00
BIND_NOW \
Add built-in ccache build support via WITH_CCACHE_BUILD option. ccache is mostly beneficial for frequent builds where -DNO_CLEAN is not used to achieve a safe pseudo-incremental build. This is explained in more detail upstream [1] [2]. It incurs about a 20%-28% hit to populate the cache, but with a full cache saves 30-50% in build times. When combined with the WITH_FAST_DEPEND feature it saves up to 65% since ccache does cache the resulting dependency file, which it does not do when using mkdep(1)/'CC -E'. Stats are provided at the end of this message. This removes the need to modify /etc/make.conf with the CC:= and CXX:= lines which conflicted with external compiler support [3] (causing the bootstrap compiler to not be built which lead to obscure failures [4]), incorrectly invoked ccache in various stages, required CCACHE_CPP2 to avoid Clang errors with parenthesis, and did not work with META_MODE. The option name was picked to match the existing option in ports. This feature is available for both in-src and out-of-src builds that use /usr/share/mk. Linking, assembly compiles, and pre-processing avoid using ccache since it is only overhead. ccache does nothing special in these modes, although there is no harm in calling it for them. CCACHE_COMPILERCHECK is set to 'content' when using the in-tree bootstrap compiler to hash the content of the compiler binary to determine if it should be a cache miss. For external compilers the 'mtime' option is used as it is more efficient and likely to be correct. Future work may optimize the 'content' check using the same checks as whether a bootstrap compiler is needed to be built. The CCACHE_CPP2 pessimization is currently default in our devel/ccache port due to Clang requiring it. Clang's -Wparentheses-equality, -Wtautological-compare, and -Wself-assign warnings do not mix well with compiling already-pre-processed code that may have expanded macros that trigger the warnings. GCC has so far not had this issue so it is allowed to disable the CCACHE_CPP2 default in our port. Sharing a cache between multiple checkouts, or systems, is explained in the ccache manual. Sharing a cache over NFS would likely not be worth it, but syncing cache directories between systems may be useful for an organization. There is also a memcached backend available [5]. Due to using an object directory outside of the source directory though you will need to ensure that both are in the same prefix and all users use the same layout. A possible working layout is as follows: Source: /some/prefix/src1 Source: /some/prefix/src2 Source: /some/prefix/src3 Objdir: /some/prefix/obj Environment: CCACHE_BASEDIR='${SRCTOP:H}' MAKEOBJDIRPREFIX='${SRCTOP:H}/obj' This will use src*/../obj as the MAKEOBJDIRPREFIX and tells ccache to replace all absolute paths to be relative. Using something like this is required due to -I and -o flags containing both SRC and OBJDIR absolute paths that ccache adds into its hash for the object without CCACHE_BASEDIR. distcc can be hooked into by setting CCACHE_PREFIX=/usr/local/bin/distcc. I have not personally tested this and assume it will not mix well with using the bootstrap compiler. The cache from buildworld can be reused in a subdir by first running 'make buildenv' (from r290424). Note that the cache is currently different depending on whether -j is used or not due to ccache enabling -fdiagnostics-color automatically if stderr is a TTY, which bmake only does if not using -j. The system I used for testing was: WITNESS Build options: -j20 WITH_LLDB=yes WITH_DEBUG_FILES=yes WITH_CCACHE_BUILD=yes DISK: ZFS 3-way mirror with very slow disks using SSD l2arc/log. The arc was fully populated with src tree files and ccache objects. RAM: 76GiB CPU: Intel(R) Xeon(R) CPU L5520 @2.27GHz 2 package(s) x 4 core(s) x 2 SMT threads = hw.ncpu=16 The WITH_FAST_DEPEND feature was used for comparison here as well to show the dramatic time savings with a full cache. buildworld: x buildworld-before + buildworld-ccache-empty * buildworld-ccache-full % buildworld-ccache-full-fastdep # buildworld-fastdep +-------------------------------------------------------------------------------+ |% * # +| |% * # +| |% * # xxx +| | |A | | A| | A | |A | | A | +-------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 3744.13 3794.31 3752.25 3763.5633 26.935139 + 3 4519 4525.04 4520.73 4521.59 3.1104823 Difference at 95.0% confidence 758.027 +/- 43.4565 20.1412% +/- 1.15466% (Student's t, pooled s = 19.1726) * 3 1823.08 1827.2 1825.62 1825.3 2.0785572 Difference at 95.0% confidence -1938.26 +/- 43.298 -51.5007% +/- 1.15045% (Student's t, pooled s = 19.1026) % 3 1266.96 1279.37 1270.47 1272.2667 6.3971113 Difference at 95.0% confidence -2491.3 +/- 44.3704 -66.1952% +/- 1.17895% (Student's t, pooled s = 19.5758) # 3 3153.34 3155.16 3154.2 3154.2333 0.91045776 Difference at 95.0% confidence -609.33 +/- 43.1943 -16.1902% +/- 1.1477% (Student's t, pooled s = 19.0569) buildkernel: x buildkernel-before + buildkernel-ccache-empty * buildkernel-ccache-empty-fastdep % buildkernel-ccache-full # buildkernel-ccache-full-fastdep @ buildkernel-fastdep +-------------------------------------------------------------------------------+ |# @ % * | |# @ % * x + | |# @ % * xx ++| | MA | | MA| | A | | A | |A | | A | +-------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 571.57 573.94 571.79 572.43333 1.3094401 + 3 727.97 731.91 728.06 729.31333 2.2492295 Difference at 95.0% confidence 156.88 +/- 4.17129 27.4058% +/- 0.728695% (Student's t, pooled s = 1.84034) * 3 527.1 528.29 528.08 527.82333 0.63516402 Difference at 95.0% confidence -44.61 +/- 2.33254 -7.79305% +/- 0.407478% (Student's t, pooled s = 1.02909) % 3 400.4 401.05 400.62 400.69 0.3306055 Difference at 95.0% confidence -171.743 +/- 2.16453 -30.0023% +/- 0.378128% (Student's t, pooled s = 0.954969) # 3 201.94 203.34 202.28 202.52 0.73020545 Difference at 95.0% confidence -369.913 +/- 2.40293 -64.6212% +/- 0.419774% (Student's t, pooled s = 1.06015) @ 3 369.12 370.57 369.3 369.66333 0.79033748 Difference at 95.0% confidence -202.77 +/- 2.45131 -35.4225% +/- 0.428227% (Student's t, pooled s = 1.0815) [1] https://ccache.samba.org/performance.html [2] http://www.mail-archive.com/ccache@lists.samba.org/msg00576.html [3] https://reviews.freebsd.org/D3484 [5] https://github.com/jrosdahl/ccache/pull/30 PR: 182944 [4] MFC after: 3 weeks Sponsored by: EMC / Isilon Storage Division Relnotes: yes
2015-11-08 00:50:18 +00:00
CCACHE_BUILD \
Split up the options into those used only by bsd.mk.* or sys.mk and the rest. Add note of caution for the surprises that popped up. MK_SSP is the only one used by sys.mk, and it likely needs even extra attention.
2014-04-25 19:25:53 +00:00
CTF \
Support initializing stack variables on function entry There are two options: - WITH_INIT_ALL_ZERO: Zero all variables on the stack. - WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns. The exact pattern are a compiler implementation detail and vary by type. They are somewhat documented in the LLVM commit message: https://reviews.llvm.org/rL349442 I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather than naming them after the LLVM specific compiler flags. In a range of consumer products, options like these are used in both debug and production builds with debugs builds using patterns (intended to provoke crashes on use of uninitialized values) and production using zeros (deemed more likely to lead to harmless misbehavior or NULL-pointer dereferences). Reviewed by: emaste Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27131
2020-11-10 19:15:13 +00:00
INIT_ALL_PATTERN \
INIT_ALL_ZERO \
Add META_MODE support. Off by default, build behaves normally. WITH_META_MODE we get auto objdir creation, the ability to start build from anywhere in the tree. Still need to add real targets under targets/ to build packages. Differential Revision: D2796 Reviewed by: brooks imp
2015-06-13 19:20:56 +00:00
INSTALL_AS_USER \
pkgbase: Fix building out-of-tree manual pages c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for building out-of-tree manual pages. For example, x11/nvidia-driver fails with the following error: ===> doc (all) make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional (${MK_MANSPLITPKG} == "no") make[3]: Fatal errors encountered -- cannot continue Move the definition from src.opts.mk to bsd.opts.mk to make it visible.
2021-03-16 18:16:10 +00:00
MANSPLITPKG \
Introduce src.conf knob to build userland with retpoline WITH_RETPOLINE enables -mretpoline vulnerability mitigation in userland for CVE-2017-5715. Reported by: Peter Malcom Reviewed by: markj MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17421
2018-10-21 00:27:59 +00:00
RETPOLINE \
Add META_MODE support. Off by default, build behaves normally. WITH_META_MODE we get auto objdir creation, the ability to start build from anywhere in the tree. Still need to add real targets under targets/ to build packages. Differential Revision: D2796 Reviewed by: brooks imp
2015-06-13 19:20:56 +00:00
STALE_STAGED
Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
Merge from head
2015-05-26 21:52:57 +00:00
__DEFAULT_DEPENDENT_OPTIONS = \
Add limited sandbox capability to "make check" == Rationale == r295380 introduced "make check" and consolidated means for running test code in an attempt to simplify running tests. One could either install files/libraries/programs and run "make check", or run "make check" with an explicit CHECKDIR, e.g., `make check CHECKDIR=$(make -V.OBJDIR)``. One criticism that was received is that "make check" should be run with the intent of making dev->test->commit easier, which means that the target audience's workflow should be developers. One developer pattern available in other opensource projects is to run test code from a developer sandbox, instead of installing to a system. == Method == This approach is slightly different from the standard approach, in the sense that it builds and installs into a deterministic directory under .OBJDIR (as I call it, the "sandbox"), then runs "make check" against that. In the event the test run is successful, the deterministic directory is removed to save space. == Approach == bsd.lib.mk, bsd.prog.mk: To support this functionality, a new variable `HAS_TESTS` is being added. HAS_TESTS enables appropriate behavior with bsd.lib.mk and bsd.prog.mk, as follows: - Add "make check" as an available target from the directory. - Pass down appropriate variables via ${TESTS_ENV}, i.e., ${TESTS_LD_LIBRARY_PATH} and ${TESTS_PATH}. One should add "HAS_TESTS" to directories containing tests in them, e.g. from bin/sh/Makefile, HAS_TESTS= SUBDIR.${MK_TESTS}+= tests HAS_TESTS doesn't automatically add the tests subdirectory for flexibility reasons. bsd.opts.mk, src.opts.mk: - The knob ${MK_MAKE_CHECK_USE_SANDBOX} has been added, both to explicitly direct (internally) when to set a deterministic ${DESTDIR} and to also allow users to disable this behavior globally, i.e., via src.conf. - MK_TESTS has been promoted from src.opts.mk to bsd.opts.mk to leverage syntactic sugar for having MK_TESTS be a dependency for MK_MAKE_CHECK_USE_SANDBOX, but to also ensure that src.opts.mk isn't required to use suite.test.mk (which is a dependency of bsd.test.mk). suite.test.mk: - beforecheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Build. -- Run "make hierarchy" on the sandbox dir. -- Install the tests/files to the sandbox dir. - aftercheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified from a no-op to: -- Remove the sandbox dir. Again, because the dependency order set in bsd.test.mk is beforecheck -> check -> aftercheck, "make check" will not be run unless "beforecheck" completes successfully, and "aftercheck" will not be run unless "beforecheck" and "check" complete successfully. == Caveats == - This target must either be run with MK_INSTALL_AS_USER or as root. Otherwise it will fail when running "make install" as the default user/group for many makefiles when calling INSTALL is root/wheel. - This target must be run from a suitable top-level directory. For example, running tests from `tests/sys/fs/tmpfs` won't work, but `tests/sys/fs` will, because `tests/sys/fs/tmpfs` relies on files installed by `tests/sys/fs`. - Running MK_INSTALL_AS_USER may introduce determinism issues. However, using it could identify deficiences in tests in terms of needing to be run as root, which are not properly articulated in the test requirements. - The doesn't negate the need for running "make installworld" and "make checkworld", etc. Again, this just is intended to simplify the dev->test->commit workflow. == Cleanup done == - CHECKDIR is removed; one can use "MK_MAKE_CHECK_USE_SANDBOX=no" to enable "legacy" (r295380) behavior. MFC after: 2 months Relnotes: yes (CHECKDIR removed; "make check" behavior changed) Requested by: jhb Reviewed by: arch (silence), testing (silence) Differential Revision: D11905
2017-08-14 19:03:05 +00:00
MAKE_CHECK_USE_SANDBOX/TESTS \
Add dependent option STAGING_MAN/STAGING Use a single mlinks set, since some libs (eg. libc) do cross section links.
2015-06-04 19:11:56 +00:00
STAGING_MAN/STAGING \
Add META_MODE support. Off by default, build behaves normally. WITH_META_MODE we get auto objdir creation, the ability to start build from anywhere in the tree. Still need to add real targets under targets/ to build packages. Differential Revision: D2796 Reviewed by: brooks imp
2015-06-13 19:20:56 +00:00
STAGING_PROG/STAGING \
Use __DEFAULT_DEPENDENT_OPTIONS for articulating dependency relationship between MK_STALE_STAGED and MK_STAGING instead of using equivalent ad hoc logic. MFC after: 1 month
2017-07-24 18:21:01 +00:00
STALE_STAGED/STAGING \
Hook the meta/nofilemon build into using FAST_DEPEND. FAST_DEPEND is intended to be the "skip 'make depend' and mkdep" feature. Since DIRDEPS_BUILD does this already with some of its own hacks, and filemon doesn't need this, and nofilemon does, teach it how to handle each of these cases. In meta+filemon mode filemon will handle dependencies itself via the meta mode logic in bmake. We still want to set MK_FAST_DEPEND=yes to enable some logic that indicates that 'make depend' is skipped in the traditional sense. The actual .depend.* files will be skipped. When nofilemon is set though we still need to track and generate dependencies. Sponsored by: EMC / Isilon Storage Division
2016-02-24 17:19:13 +00:00
Enable PIE by default on 64-bit architectures This patch adds Position Independent Executables (PIE) flags for building OS. It allows to enable the ASLR feature based only on the sysctl knobs, without need to rebuild the image. Tests showed that no problems with stability / performance degradation were seen when using PIEs with ASLR disabled. The change is limited only for 64-bit architectures. Use bsd.opts.mk instead of the src.opts.mk in order to satisfy all build dependencies related to MK_PIE. Reviewed by: emaste, imp Obtained from: Semihalf Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D28328
2021-01-22 12:13:03 +00:00
#
# Default to disabling PIE on 32-bit architectures. The small address space
# means that ASLR is of limited effectiveness, and it may cause issues with
# some memory-hungry workloads.
#
.if ${MACHINE_ARCH} == "armv6" || ${MACHINE_ARCH} == "armv7" \
|| ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "mips" \
|| ${MACHINE_ARCH} == "mipsel" || ${MACHINE_ARCH} == "mipselhf" \
|| ${MACHINE_ARCH} == "mipshf" || ${MACHINE_ARCH} == "mipsn32" \
|| ${MACHINE_ARCH} == "mipsn32el" || ${MACHINE_ARCH} == "powerpc" \
|| ${MACHINE_ARCH} == "powerpcspe"
__DEFAULT_NO_OPTIONS+= PIE
.else
__DEFAULT_YES_OPTIONS+=PIE
.endif
Hook the meta/nofilemon build into using FAST_DEPEND. FAST_DEPEND is intended to be the "skip 'make depend' and mkdep" feature. Since DIRDEPS_BUILD does this already with some of its own hacks, and filemon doesn't need this, and nofilemon does, teach it how to handle each of these cases. In meta+filemon mode filemon will handle dependencies itself via the meta mode logic in bmake. We still want to set MK_FAST_DEPEND=yes to enable some logic that indicates that 'make depend' is skipped in the traditional sense. The actual .depend.* files will be skipped. When nofilemon is set though we still need to track and generate dependencies. Sponsored by: EMC / Isilon Storage Division
2016-02-24 17:19:13 +00:00
Move the generic part of bsd.opts.mk into bsd.mkopts.mk to allow for the WITH/WITHOUT_FOO -> MK_FOO={yes,no} stuff to be used elsewhere.
2014-04-18 17:04:26 +00:00
.include <bsd.mkopt.mk>
Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
Support initializing stack variables on function entry There are two options: - WITH_INIT_ALL_ZERO: Zero all variables on the stack. - WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns. The exact pattern are a compiler implementation detail and vary by type. They are somewhat documented in the LLVM commit message: https://reviews.llvm.org/rL349442 I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather than naming them after the LLVM specific compiler flags. In a range of consumer products, options like these are used in both debug and production builds with debugs builds using patterns (intended to provoke crashes on use of uninitialized values) and production using zeros (deemed more likely to lead to harmless misbehavior or NULL-pointer dereferences). Reviewed by: emaste Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27131
2020-11-10 19:15:13 +00:00
.if ${MK_INIT_ALL_PATTERN} == "yes" && ${MK_INIT_ALL_ZERO} == "yes"
Fix `make makeman` after r367577 WITH_INIT_ALL_ZERO and WITH_INIT_ALL_PATTERN are mutually exclusive. The .error when they were both set broke makeman so demote it to a warning (and presumably the compiler will fail on an error later on). We could improve this to make one take precedence but this is sufficient for now. MFC with: r367577 Sponsored by: The FreeBSD Foundation
2020-11-13 19:08:42 +00:00
.warning WITH_INIT_ALL_PATTERN and WITH_INIT_ALL_ZERO are mutually exclusive.
Support initializing stack variables on function entry There are two options: - WITH_INIT_ALL_ZERO: Zero all variables on the stack. - WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns. The exact pattern are a compiler implementation detail and vary by type. They are somewhat documented in the LLVM commit message: https://reviews.llvm.org/rL349442 I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather than naming them after the LLVM specific compiler flags. In a range of consumer products, options like these are used in both debug and production builds with debugs builds using patterns (intended to provoke crashes on use of uninitialized values) and production using zeros (deemed more likely to lead to harmless misbehavior or NULL-pointer dereferences). Reviewed by: emaste Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27131
2020-11-10 19:15:13 +00:00
.endif
All the NO_foo options processed in src.opts.mk are really bsd.opts.mk options, so move their processing there. This fixes issues with Makefiles that define NO_MAN=t and only inlcude bsd.*.mk files. A few ports fell into this category, and they should be fixed by this change. Also, for now, disable the warning about NO_foo being deprecated. More work is needed than anticipated before we can do that, so kill the noise for now.
2014-05-07 18:14:56 +00:00
#
# Supported NO_* options (if defined, MK_* will be forced to "no",
# regardless of user's setting).
#
# These are transitional and will disappaer in the FreeBSD 12.
#
.for var in \
CTF \
DEBUG_FILES \
INSTALLLIB \
MAN \
Migrate NO_WARN to MK_WARN. Support legacy NO_WARN usage. Remove a check for EARLY_BUILD because it isn't necessary (MK_WARN=no will always be defined for that).
2014-05-10 16:37:53 +00:00
PROFILE \
Rename NO_WERROR -> MK_WERROR=no As suggested in D27598. This also supports MK_WERROR.clang=no and MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses. Reviewed By: brooks Differential Revision: https://reviews.freebsd.org/D27601
2021-01-06 17:55:06 +00:00
WARNS \
WERROR
All the NO_foo options processed in src.opts.mk are really bsd.opts.mk options, so move their processing there. This fixes issues with Makefiles that define NO_MAN=t and only inlcude bsd.*.mk files. A few ports fell into this category, and they should be fixed by this change. Also, for now, disable the warning about NO_foo being deprecated. More work is needed than anticipated before we can do that, so kill the noise for now.
2014-05-07 18:14:56 +00:00
.if defined(NO_${var})
Make the warning for deprecated NO_ variables an error. Support for NO_CTF, NO_DEBUG_FILES, NO_INSTALLLIB, NO_MAN, NO_PROFILE, and NO_WARNS as deprecated in 2014 with a warning added for each one found. Turn these into error in preperation for removal of compatability support before FreeBSD 13. This was previously committed in r354909 and reverted in r355011 due to unforseen impacts on ports. I've since corrected all amd64 and i386 ports reported in prior runs as well as instance of these variables I found via grep.
2020-02-12 18:09:20 +00:00
.error "NO_${var} is defined, but deprecated. Please use MK_${var}=no instead."
All the NO_foo options processed in src.opts.mk are really bsd.opts.mk options, so move their processing there. This fixes issues with Makefiles that define NO_MAN=t and only inlcude bsd.*.mk files. A few ports fell into this category, and they should be fixed by this change. Also, for now, disable the warning about NO_foo being deprecated. More work is needed than anticipated before we can do that, so kill the noise for now.
2014-05-07 18:14:56 +00:00
MK_${var}:=no
.endif
.endfor
Move the inclusion of bsd.cpu.mk from sys.mk to bsd.opts.mk. However, for historical behavior that ports depends on, include it if we're inside the ports tree. Differential Review: https://reviews.freebsd.org/D4383 Ports Exp run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205021
2015-12-11 05:39:44 +00:00
.include <bsd.cpu.mk>
Copy bsd.own.mk to bsd.opts.mk and separate out the option setting code from the rest. Include bsd.opts.mk in bsd.own.mk to preserve current behavior. Future revisions will replace the inclusion of bsd.own.mk elsewhere with bsd.opts.mk or a more appropriate new file that's still being finalized.
2014-04-18 17:04:09 +00:00
.endif # !_WITHOUT_SRCCONF
.endif
Reference in New Issue Copy Permalink