NixOS/nix
NixOS/nix
1
0
Fork 0
mirror of https://github.com/NixOS/nix synced 2024-09-19 23:03:53 -04:00
Code Activity
nix/nix-rust/local.mk

49 lines
1.4 KiB
Makefile
Raw Normal View History

When OPTIMIZE=0, build rust code in debug mode
2019-11-27 08:18:57 -05:00
ifeq ($(OPTIMIZE), 1)
RUST_MODE = --release
RUST_DIR = release
else
RUST_MODE =
RUST_DIR = debug
endif
Make libnixrust a dynamic library This is a hack to fix the build on macOS, which was failing because libnixrust.a contains compiler builtins that clash with libclang_rt.osx.a. There's probably a better solution... https://hydra.nixos.org/build/107473280
2019-11-29 12:27:40 -05:00
libnixrust_PATH := $(d)/target/$(RUST_DIR)/libnixrust.$(SO_EXT)
libnixrust_INSTALL_PATH := $(libdir)/libnixrust.$(SO_EXT)
Only link with libdl on Linux Linux is (as far as I know) the only mainstream operating system that requires linking with libdl for dlopen. On BSD, libdl doesn't exist, so on non-FreeBSD BSDs linking will currently fail. On macOS, it's apparently just a symlink to libSystem (macOS libc), presumably present for compatibility with things that assume Linux. So the right thing to do here is to only add -ldl on Linux, not to add it for everything that isn't FreeBSD.
2021-05-17 13:08:57 -04:00
libnixrust_LDFLAGS_USE := -L$(d)/target/$(RUST_DIR) -lnixrust
libnixrust_LDFLAGS_USE_INSTALLED := -L$(libdir) -lnixrust
Apply OS checks to host platform, not build Previously, the build system used uname(1) output when it wanted to check the operating system it was being built for, which meant that it didn't take into-account cross-compilation when the build and host operating systems were different. To fix this, instead of consulting uname output, we consult the host triple, specifically the third "kernel" part. For "kernel"s with stable ABIs, like Linux or Cygwin, we can use a simple ifeq to test whether we're compiling for that system, but for other platforms, like Darwin, FreeBSD, or Solaris, we have to use a more complicated check to take into account the version numbers at the end of the "kernel"s. I couldn't find a way to just strip these version numbers in GNU Make without shelling out, which would be even more ugly IMO. Because these checks differ between kernels, and the patsubst ones are quite fiddly, I've added variables for each host OS we might want to check to make them easier to reuse.
2021-06-01 03:58:21 -04:00
ifdef HOST_LINUX
Only link with libdl on Linux Linux is (as far as I know) the only mainstream operating system that requires linking with libdl for dlopen. On BSD, libdl doesn't exist, so on non-FreeBSD BSDs linking will currently fail. On macOS, it's apparently just a symlink to libSystem (macOS libc), presumably present for compatibility with things that assume Linux. So the right thing to do here is to only add -ldl on Linux, not to add it for everything that isn't FreeBSD.
2021-05-17 13:08:57 -04:00
libnixrust_LDFLAGS_USE += -ldl
libnixrust_LDFLAGS_USE_INSTALLED += -ldl
endif
Add some Rust code
2019-03-27 09:12:20 -04:00
Apply OS checks to host platform, not build Previously, the build system used uname(1) output when it wanted to check the operating system it was being built for, which meant that it didn't take into-account cross-compilation when the build and host operating systems were different. To fix this, instead of consulting uname output, we consult the host triple, specifically the third "kernel" part. For "kernel"s with stable ABIs, like Linux or Cygwin, we can use a simple ifeq to test whether we're compiling for that system, but for other platforms, like Darwin, FreeBSD, or Solaris, we have to use a more complicated check to take into account the version numbers at the end of the "kernel"s. I couldn't find a way to just strip these version numbers in GNU Make without shelling out, which would be even more ugly IMO. Because these checks differ between kernels, and the patsubst ones are quite fiddly, I've added variables for each host OS we might want to check to make them easier to reuse.
2021-06-01 03:58:21 -04:00
ifdef HOST_DARWIN
Make libnixrust a dynamic library This is a hack to fix the build on macOS, which was failing because libnixrust.a contains compiler builtins that clash with libclang_rt.osx.a. There's probably a better solution... https://hydra.nixos.org/build/107473280
2019-11-29 12:27:40 -05:00
libnixrust_BUILD_FLAGS = NIX_LDFLAGS="-undefined dynamic_lookup"
else
libnixrust_LDFLAGS_USE += -Wl,-rpath,$(abspath $(d)/target/$(RUST_DIR))
libnixrust_LDFLAGS_USE_INSTALLED += -Wl,-rpath,$(libdir)
endif
Move stuff around
2019-09-15 17:09:30 -04:00
$(libnixrust_PATH): $(call rwildcard, $(d)/src, *.rs) $(d)/Cargo.toml
When OPTIMIZE=0, build rust code in debug mode
2019-11-27 08:18:57 -05:00
$(trace-gen) cd nix-rust && CARGO_HOME=$$(if [[ -d vendor ]]; then echo vendor; fi) \
Make libnixrust a dynamic library This is a hack to fix the build on macOS, which was failing because libnixrust.a contains compiler builtins that clash with libclang_rt.osx.a. There's probably a better solution... https://hydra.nixos.org/build/107473280
2019-11-29 12:27:40 -05:00
$(libnixrust_BUILD_FLAGS) \
Update to async/await-enabled tokio
2019-12-04 09:32:28 -05:00
cargo build $(RUST_MODE) $$(if [[ -d vendor ]]; then echo --offline; fi) \
Make libnixrust a dynamic library This is a hack to fix the build on macOS, which was failing because libnixrust.a contains compiler builtins that clash with libclang_rt.osx.a. There's probably a better solution... https://hydra.nixos.org/build/107473280
2019-11-29 12:27:40 -05:00
&& touch target/$(RUST_DIR)/libnixrust.$(SO_EXT)
$(libnixrust_INSTALL_PATH): $(libnixrust_PATH)
$(target-gen) cp $^ $@
Apply OS checks to host platform, not build Previously, the build system used uname(1) output when it wanted to check the operating system it was being built for, which meant that it didn't take into-account cross-compilation when the build and host operating systems were different. To fix this, instead of consulting uname output, we consult the host triple, specifically the third "kernel" part. For "kernel"s with stable ABIs, like Linux or Cygwin, we can use a simple ifeq to test whether we're compiling for that system, but for other platforms, like Darwin, FreeBSD, or Solaris, we have to use a more complicated check to take into account the version numbers at the end of the "kernel"s. I couldn't find a way to just strip these version numbers in GNU Make without shelling out, which would be even more ugly IMO. Because these checks differ between kernels, and the patsubst ones are quite fiddly, I've added variables for each host OS we might want to check to make them easier to reuse.
2021-06-01 03:58:21 -04:00
ifdef HOST_DARWIN
Make libnixrust a dynamic library This is a hack to fix the build on macOS, which was failing because libnixrust.a contains compiler builtins that clash with libclang_rt.osx.a. There's probably a better solution... https://hydra.nixos.org/build/107473280
2019-11-29 12:27:40 -05:00
install_name_tool -id $@ $@
endif
Include cargo dependencies in the Nix tarball
2019-07-04 19:01:18 -04:00
make clean: Delete nix-rust/target
2019-11-27 11:33:59 -05:00
clean: clean-rust
clean-rust:
$(suppress) rm -rfv nix-rust/target
Add base32 encoder/decoder
2019-09-16 18:18:17 -04:00
Apply OS checks to host platform, not build Previously, the build system used uname(1) output when it wanted to check the operating system it was being built for, which meant that it didn't take into-account cross-compilation when the build and host operating systems were different. To fix this, instead of consulting uname output, we consult the host triple, specifically the third "kernel" part. For "kernel"s with stable ABIs, like Linux or Cygwin, we can use a simple ifeq to test whether we're compiling for that system, but for other platforms, like Darwin, FreeBSD, or Solaris, we have to use a more complicated check to take into account the version numbers at the end of the "kernel"s. I couldn't find a way to just strip these version numbers in GNU Make without shelling out, which would be even more ugly IMO. Because these checks differ between kernels, and the patsubst ones are quite fiddly, I've added variables for each host OS we might want to check to make them easier to reuse.
2021-06-01 03:58:21 -04:00
ifndef HOST_DARWIN
Add base32 encoder/decoder
2019-09-16 18:18:17 -04:00
check: rust-tests
rust-tests:
make check: Run unit tests
2020-05-08 05:49:40 -04:00
$(trace-test) cd nix-rust && CARGO_HOME=$$(if [[ -d vendor ]]; then echo vendor; fi) cargo test --release $$(if [[ -d vendor ]]; then echo --offline; fi)
Make the Store API more type-safe Most functions now take a StorePath argument rather than a Path (which is just an alias for std::string). The StorePath constructor ensures that the path is syntactically correct (i.e. it looks like <store-dir>/<base32-hash>-<name>). Similarly, functions like buildPaths() now take a StorePathWithOutputs, rather than abusing Path by adding a '!<outputs>' suffix. Note that the StorePath type is implemented in Rust. This involves some hackery to allow Rust values to be used directly in C++, via a helper type whose destructor calls the Rust type's drop() function. The main issue is the dynamic nature of C++ move semantics: after we have moved a Rust value, we should not call the drop function on the original value. So when we move a value, we set the original value to bitwise zero, and the destructor only calls drop() if the value is not bitwise zero. This should be sufficient for most types. Also lots of minor cleanups to the C++ API to make it more modern (e.g. using std::optional and std::string_view in some places).
2019-12-05 13:11:09 -05:00
endif
Copy permalink