keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
60e605b34e
rpm-ostree/Makefile.bindings

34 lines
1.1 KiB
Makefile
Raw Normal View History

Makefile.bindings: Use content-based change detection We've had a problem for a long time that e.g. `rpmostree-rust.h` didn't have dependencies on the relevant Rust sources, so changing it required `rm -f rpmostree-rust && make` which is very confusing. Improve things here for both it and cxx.rs so that we use content-based change detection (this is a default in more modern build systems). This way e.g. `touch Cargo.toml && make` won't implicitly result in rebuilding all of the C/C++ side.
2021-01-02 18:38:05 +03:00
# This is duplicated with LIBRPMOSTREE_RUST_SRCS because this
# Makefile needs to be independent
binding_rust_sources = $(shell find rust/src/ -name '*.rs') Cargo.toml Cargo.lock cbindgen.toml
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +03:00
# A plain Makefile (not automake) so that we can run this logic
# without running the autotools.
Makefile.bindings: Use content-based change detection We've had a problem for a long time that e.g. `rpmostree-rust.h` didn't have dependencies on the relevant Rust sources, so changing it required `rm -f rpmostree-rust && make` which is very confusing. Improve things here for both it and cxx.rs so that we use content-based change detection (this is a default in more modern build systems). This way e.g. `touch Cargo.toml && make` won't implicitly result in rebuilding all of the C/C++ side.
2021-01-02 18:38:05 +03:00
rpmostree-rust.h: $(binding_rust_sources)
$(AM_V_GEN) if cbindgen -c cbindgen.toml -o $@.tmp $(top_srcdir); then \
if test -f $@ && cmp $@.tmp $@ 2>/dev/null; then rm -f $@.tmp; else \
mv $@.tmp $@; \
fi; \
else \
echo cbindgen failed; exit 1; \
fi
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +03:00
BUILT_SOURCES += rpmostree-rust.h
Makefile.bindings: Also generate pure rust/cxx.h This is necessary in order to use `rust::` in our header files that are also used by bindings.
2021-01-27 04:35:37 +03:00
rust/cxx.h: Makefile.bindings
cxxbridge --header >$@
Makefile.bindings: Use content-based change detection We've had a problem for a long time that e.g. `rpmostree-rust.h` didn't have dependencies on the relevant Rust sources, so changing it required `rm -f rpmostree-rust && make` which is very confusing. Improve things here for both it and cxx.rs so that we use content-based change detection (this is a default in more modern build systems). This way e.g. `touch Cargo.toml && make` won't implicitly result in rebuilding all of the C/C++ side.
2021-01-02 18:38:05 +03:00
rpmostree-cxxrs.h: $(binding_rust_sources)
$(AM_V_GEN) if cxxbridge rust/src/lib.rs --header > $@.tmp; then \
if test -f $@ && cmp $@.tmp $@ 2>/dev/null; then rm -f $@.tmp; else \
mv $@.tmp $@; \
fi; \
else \
echo cxxbridge failed; exit 1; \
fi
rpmostree-cxxrs.cxx: $(binding_rust_sources) rpmostree-cxxrs.h
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +03:00
$(AM_V_GEN) cxxbridge --include rpmostree-cxxrs.h rust/src/lib.rs > $@
# Invoked in CI
Makefile.bindings: Also generate pure rust/cxx.h This is necessary in order to use `rust::` in our header files that are also used by bindings.
2021-01-27 04:35:37 +03:00
bindings: rpmostree-rust.h rpmostree-cxxrs.h rpmostree-cxxrs.cxx rust/cxx.h
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +03:00
.PHONY: bindings
Reference in New Issue Copy Permalink