puck/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity
lix/Makefile

88 lines
2.4 KiB
Makefile
Raw Normal View History

Use `buildprefix` in a few more places `installcheck` doesn't yet work, but the rest of the build can now happen mostly inside a separate build directory. Progress on #9342 Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-11-25 05:33:21 +00:00
include mk/build-dir.mk
-include $(buildprefix)Makefile.config
clean-files += $(buildprefix)Makefile.config
Use positive source filtering for the standalone functional tests job Additionally this skipping of the building is reimplemented to be a bit more robust and use the same idioms as the functionality for skipping the tests. In particular, it will now work even if the source files exist, so we can do this during development too.
2023-10-06 15:57:31 +00:00
ifeq ($(ENABLE_BUILD), yes)
Update Makefile variable names
2014-02-01 11:23:14 +00:00
makefiles = \
Fix Perl bindings
2019-11-07 11:18:37 +00:00
mk/precompiled-headers.mk \
Fix "make dist"
2014-02-01 13:28:31 +00:00
local.mk \
Rename Makefile -> local.mk
2014-01-30 11:11:06 +00:00
src/libutil/local.mk \
src/libstore/local.mk \
Move fetchers from libstore to libfetchers
2020-03-30 12:03:28 +00:00
src/libfetchers/local.mk \
Rename Makefile -> local.mk
2014-01-30 11:11:06 +00:00
src/libmain/local.mk \
src/libexpr/local.mk \
Move command plugin interface to libnixcmd
2021-01-26 11:22:24 +00:00
src/libcmd/local.mk \
Start of new Nix command-line interface
2016-02-09 20:28:29 +00:00
src/nix/local.mk \
resolve-system-dependencies: implement in C++
2016-08-13 18:36:22 +00:00
src/resolve-system-dependencies/local.mk \
Rename Makefile -> local.mk
2014-01-30 11:11:06 +00:00
scripts/local.mk \
nix: Implement basic bash completion
2020-05-10 18:32:21 +00:00
misc/bash/local.mk \
Add a fish completion script This is only rudimentary support as allowed by `NIX_GET_COMPLETIONS`. In the future, we could use complete’s `--wraps` argument to autocomplete arguments for programs after `nix shell -c`.
2021-06-01 22:45:03 +00:00
misc/fish/local.mk \
Install zsh completion script
2021-06-01 16:44:03 +00:00
misc/zsh/local.mk \
Install systemd units
2014-04-07 09:18:54 +00:00
misc/systemd/local.mk \
Add a launchd configuration file to run nix-daemon
2014-11-04 09:14:18 +00:00
misc/launchd/local.mk \
Docs build: depend on locally built nix executable and not installed one Previously many of the documentation targets were depending on `$(bindir)/nix` which is the installed version. This meant that its install rules would be triggered (which in chain would also trigger the install of libraries, as reported in #5140). Therefore a build of the documentation without an installation would not be possible (which apart from doing unwanted operations it may also generate permission problems for example). The fix makes the rules depend on `$(nix_PATH)` instead, which is the executable in the build tree.
2021-08-17 02:26:41 +00:00
misc/upstart/local.mk
Use positive source filtering for the standalone functional tests job Additionally this skipping of the building is reimplemented to be a bit more robust and use the same idioms as the functionality for skipping the tests. In particular, it will now work even if the source files exist, so we can do this during development too.
2023-10-06 15:57:31 +00:00
endif
Rename Makefile.new -> Makefile
2013-11-25 15:25:13 +00:00
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
ifeq ($(ENABLE_UNIT_TESTS), yes)
Add ./configure --disable-tests option Building without tests is useful for bootstrapping with a smaller footprint or running the tests in a separate derivation. Otherwise, we do compile and run them. This isn't fine grained as to allow picking `check` but not `installcheck` or vice versa, but it's good enough for now. I've tried to use Nixpkgs' `checkInputs`, but those inputs weren't discovered properly by the configure script. We can emulate its behavior very well though.
2023-02-20 19:27:50 +00:00
makefiles += \
Move tests to separate directories, and document Today, with the tests inside a `tests` intermingled with the corresponding library's source code, we have a few problems: - We have to be careful that wildcards don't end up with tests being built as part of Nix proper, or test headers being installed as part of Nix proper. - Tests in libraries but not executables is not right: - It means each executable runs the previous unit tests again, because it needs the libraries. - It doesn't work right on Windows, which doesn't want you to load a DLL just for the side global variable . It could be made to work with the dlopen equivalent, but that's gross! This reorg solves these problems. There is a remaining problem which is that sibbling headers (like `hash.hh` the test header vs `hash.hh` the main `libnixutil` header) end up shadowing each other. This PR doesn't solve that. That is left as future work for a future PR. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-08-25 14:20:28 +00:00
tests/unit/libutil/local.mk \
tests/unit/libutil-support/local.mk \
tests/unit/libstore/local.mk \
tests/unit/libstore-support/local.mk \
tests/unit/libexpr/local.mk \
tests/unit/libexpr-support/local.mk
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
else
.PHONY: check
check:
@echo "Unit tests are disabled. Configure without '--disable-unit-tests', or avoid calling 'make check'."
@exit 1
Use positive source filtering for the standalone functional tests job Additionally this skipping of the building is reimplemented to be a bit more robust and use the same idioms as the functionality for skipping the tests. In particular, it will now work even if the source files exist, so we can do this during development too.
2023-10-06 15:57:31 +00:00
endif
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
ifeq ($(ENABLE_FUNCTIONAL_TESTS), yes)
Use positive source filtering for the standalone functional tests job Additionally this skipping of the building is reimplemented to be a bit more robust and use the same idioms as the functionality for skipping the tests. In particular, it will now work even if the source files exist, so we can do this during development too.
2023-10-06 15:57:31 +00:00
makefiles += \
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 16:12:18 +00:00
tests/functional/local.mk \
tests/functional/ca/local.mk \
tests/functional/dyn-drv/local.mk \
tests/functional/test-libstoreconsumer/local.mk \
tests/functional/plugins/local.mk
Add ./configure --disable-tests option Building without tests is useful for bootstrapping with a smaller footprint or running the tests in a separate derivation. Otherwise, we do compile and run them. This isn't fine grained as to allow picking `check` but not `installcheck` or vice versa, but it's good enough for now. I've tried to use Nixpkgs' `checkInputs`, but those inputs weren't discovered properly by the configure script. We can emulate its behavior very well though.
2023-02-20 19:27:50 +00:00
else
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
.PHONY: installcheck
installcheck:
@echo "Functional tests are disabled. Configure without '--disable-functional-tests', or avoid calling 'make installcheck'."
@exit 1
Add ./configure --disable-tests option Building without tests is useful for bootstrapping with a smaller footprint or running the tests in a separate derivation. Otherwise, we do compile and run them. This isn't fine grained as to allow picking `check` but not `installcheck` or vice versa, but it's good enough for now. I've tried to use Nixpkgs' `checkInputs`, but those inputs weren't discovered properly by the configure script. We can emulate its behavior very well though.
2023-02-20 19:27:50 +00:00
endif
Revert "autoconf: Allow overriding CFLAGS/CXXFLAGS from outside." This reverts commit 717e821b99797845e1bef47d862f8cb0fb69cfc9. It's much more convenient to do 'make OPTIMIZE=0'.
2019-11-06 15:55:37 +00:00
OPTIMIZE = 1
ifeq ($(OPTIMIZE), 1)
enable LTO in optimized builds gives 2-5% performance improvement across a board of tests. LTO is broken when using clang; some libs link fine while others crash the linker with a segfault in the llvm linker plugin. 🙁
2021-12-21 18:34:40 +00:00
GLOBAL_CXXFLAGS += -O3 $(CXXLTO)
GLOBAL_LDFLAGS += $(CXXLTO)
Revert "autoconf: Allow overriding CFLAGS/CXXFLAGS from outside." This reverts commit 717e821b99797845e1bef47d862f8cb0fb69cfc9. It's much more convenient to do 'make OPTIMIZE=0'.
2019-11-06 15:55:37 +00:00
else
Disable `FORTIFY_SOURCE` when compiling without optims Otherwise the build is cluttered with ``` /nix/store/fwpn2f7a4iqszyydw7ag61zlnp6xk5d3-glibc-2.30-dev/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] 382 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O) | ^~~~~~~ ``` when building with `OPTIMIZE=0`
2020-09-22 08:04:25 +00:00
GLOBAL_CXXFLAGS += -O0 -U_FORTIFY_SOURCE
Revert "autoconf: Allow overriding CFLAGS/CXXFLAGS from outside." This reverts commit 717e821b99797845e1bef47d862f8cb0fb69cfc9. It's much more convenient to do 'make OPTIMIZE=0'.
2019-11-06 15:55:37 +00:00
endif
Rename Makefile.new -> Makefile
2013-11-25 15:25:13 +00:00
include mk/lib.mk
Precompile headers This cuts 'make install -j6' on my laptop from 170s to 134s.
2019-11-06 15:54:18 +00:00
Docs build: depend on locally built nix executable and not installed one Previously many of the documentation targets were depending on `$(bindir)/nix` which is the installed version. This meant that its install rules would be triggered (which in chain would also trigger the install of libraries, as reported in #5140). Therefore a build of the documentation without an installation would not be possible (which apart from doing unwanted operations it may also generate permission problems for example). The fix makes the rules depend on `$(nix_PATH)` instead, which is the executable in the build tree.
2021-08-17 02:26:41 +00:00
# Must be included after `mk/lib.mk` so rules refer to variables defined
# by the library. Rules are not "lazy" like variables, unfortunately.
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
ifeq ($(ENABLE_DOC_GEN),yes)
Docs build: depend on locally built nix executable and not installed one Previously many of the documentation targets were depending on `$(bindir)/nix` which is the installed version. This meant that its install rules would be triggered (which in chain would also trigger the install of libraries, as reported in #5140). Therefore a build of the documentation without an installation would not be possible (which apart from doing unwanted operations it may also generate permission problems for example). The fix makes the rules depend on `$(nix_PATH)` instead, which is the executable in the build tree.
2021-08-17 02:26:41 +00:00
$(eval $(call include-sub-makefile, doc/manual/local.mk))
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
else
.PHONY: manual-html manpages
manual-html manpages:
@echo "Generated docs are disabled. Configure without '--disable-doc-gen', or avoid calling 'make manpages' and 'make manual-html'."
@exit 1
Docs build: depend on locally built nix executable and not installed one Previously many of the documentation targets were depending on `$(bindir)/nix` which is the installed version. This meant that its install rules would be triggered (which in chain would also trigger the install of libraries, as reported in #5140). Therefore a build of the documentation without an installation would not be possible (which apart from doing unwanted operations it may also generate permission problems for example). The fix makes the rules depend on `$(nix_PATH)` instead, which is the executable in the build tree.
2021-08-17 02:26:41 +00:00
endif
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
ifeq ($(ENABLE_INTERNAL_API_DOCS),yes)
Fix underlying build system so `--disable-build` works better - Internal API docs once again work - configure skips checks for a bunch of things it doesn't need
2023-12-03 23:12:22 +00:00
$(eval $(call include-sub-makefile, doc/internal-api/local.mk))
Split `--disable-tests`, fix cross builds It might seem obnoxious to have yet more configure flags, but I found controlling both the unit and functional tests with one flag was quite confusing because they are so different: - unit tests depending on building, functional tests don't (e.g. when we test already-built Nix) - unit tests can be installed, functional tests cannot - unit tests neeed extra libraries (GTest, RapidCheck), functional tests need extra executables (jq). - unit tests are run by `make check`, functional tests are run by `make installcheck` Really on a technical level, they seem wholly independent. Only on a human level ("they are both are tests") do they have anything in common. I had messed up the logic in cross builds because of this. Now I split the flag in two (and cleaned up a few other inconsistencies), and the logic fixed itself. Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
2023-12-14 05:05:03 +00:00
else
.PHONY: internal-api-html
internal-api-html:
@echo "Internal API docs are disabled. Configure with '--enable-internal-api-docs', or avoid calling 'make internal-api-html'."
@exit 1
endif
Docs build: depend on locally built nix executable and not installed one Previously many of the documentation targets were depending on `$(bindir)/nix` which is the installed version. This meant that its install rules would be triggered (which in chain would also trigger the install of libraries, as reported in #5140). Therefore a build of the documentation without an installation would not be possible (which apart from doing unwanted operations it may also generate permission problems for example). The fix makes the rules depend on `$(nix_PATH)` instead, which is the executable in the build tree.
2021-08-17 02:26:41 +00:00
Including `config.h` also needs `$(buildprefix)` Per the instruction in the manual, we want to run configure in a different directory so that we can configure + build for multiple platforms. That means `config.h` will be in the build directory. This is just like `Makefile.config`, which already is used with `$(buildprefix)`.
2023-12-01 22:38:34 +00:00
GLOBAL_CXXFLAGS += -g -Wall -include $(buildprefix)config.h -std=c++2a -I src
Copy permalink