employer
/
tame
1
0
Fork 0
Code Packages Releases Activity
tame/tamer/Makefile.am

106 lines
3.1 KiB
Makefile
Raw Normal View History

TAMER: Initial commit
2019-11-14 16:43:07 -05:00
## TAMER Makefile
#
Copyright year and name update Ryan Specialty Group (RSG) rebranded to Ryan Specialty after its IPO.
2023-01-17 23:09:25 -05:00
# Copyright (C) 2014-2023 Ryan Specialty, LLC.
Copyright year 2020 update
2020-03-06 11:05:18 -05:00
#
# This file is part of TAME.
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
##
tamer: Switch back to nightly toolchain This is to support two things: 1. Early switch to 2021 Edition, which is stable Oct 21; and 2. To make use of unstable const features. The rationale is that switching to nightly does not really have any significant downside for us, given that TAMER is used only by us and the only risk is that unstable features may change a bit, which can be mitigated with certain precautions. The rationale for each unstable feature will be documented as they are used, including documentation on what would be required to remove it and what functionality would be lost / need to change in doing so.
2021-10-01 09:38:31 -04:00
# `Makefile.am` is processed by Automake into `Makefile.in`, which is then
# processed by Autoconf into the final `Makefile`.
#
# The `@`-delimited variables are defined dynamically in `configure.ac`,
# which is processed by Autoconf into `configure`; they are populated based
# on the environment in which the `configure` script is invoked.
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
SHELL = /bin/bash -o pipefail
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
.DELETE_ON_ERROR:
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
.PHONY: all fix fmt check-fmt bench bench-build FORCE
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
Introduce CARGO_BUILD_FLAGS This is intended to permit passing `--release`, since dev builds are terribly slow (e.g. 6s -> 0.2s). See README.md for more information.
2019-11-27 09:17:27 -05:00
CARGO_BUILD_FLAGS=@CARGO_BUILD_FLAGS@
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS=@RUSTFLAGS@
Introduce CARGO_BUILD_FLAGS This is intended to permit passing `--release`, since dev builds are terribly slow (e.g. 6s -> 0.2s). See README.md for more information.
2019-11-27 09:17:27 -05:00
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
ontviz_svg := target/doc/tamer/asg/ontviz.svg
tamer: Makefile.am (all): Binaries and doc `all` was previously the target for binaries only.
2021-07-23 22:23:10 -04:00
.DEFAULT: bin
tamer: Makefile.am (bench-build): New target, default for all Build the benchmarks by default to catch breakages without having to incur the cost of actually running them.
2021-10-08 09:27:56 -04:00
all: bin doc bench-build
tamer: Makefile.am (all): Binaries and doc `all` was previously the target for binaries only.
2021-07-23 22:23:10 -04:00
.PHONY: bin
bin:
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ build $(CARGO_BUILD_FLAGS) @FEATURES@
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
Makefile.am (doc, html): New documentation target
2019-11-18 13:24:22 -05:00
doc: html
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
html-am: rustdoc $(ontviz_svg)
.PHONY: rustdoc
rustdoc:
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ test --doc @FEATURES@
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ @CARGO_DOC_FLAGS@ doc --document-private-items @FEATURES@
Makefile.am (doc, html): New documentation target
2019-11-18 13:24:22 -05:00
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
$(ontviz_svg): FORCE
tamer: {tools=>build-aux}/asg-ontviz Now that these are actually intended to be used as part of the build, this is a more appropriate location. I originally wrote it as a manual tool. DEV-13708
2023-03-10 15:10:13 -05:00
build-aux/asg-ontviz | $(DOT) -Tsvg > $@
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
# note that 'cargo check' is something else; see 'cargo --help'
test: check
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
check-am: check-lint check-fmt check-cargo check-docgen check-system
tamer: tests: System test support This provides a test harness for running shell-based system tests. The first of such tests will be introduced in the following commit. This is done in place of integration tests written in Rust because it will invoke the final binary exactly as the user or build system (using TAMER) will, providing greater confidence. Besides, a lot of things are simply more convenient to do in shell. ...though some of you may debate that. DEV-13708
2023-02-22 22:44:46 -05:00
.PHONY: check-cargo
check-cargo:
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ test --quiet @FEATURES@
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
tamer: Makefile.am: check-cargo-partial: New target For running individual test cases without having to break the abstraction of the Makefile and run `cargo test` directory. DEV-13163
2023-08-09 11:59:12 -04:00
# This is its _own_ target distinct from `check-cargo` because `TEST` can
# otherwise allow for filtering out failing tests and have a successful
# build.
check-cargo-partial:
@test -n "$(TEST)" || { echo 'usage: make check-partial TEST=name::of::test' >&2; exit 1; }
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ test --quiet @FEATURES@ -- $(TEST)
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
.PHONY: check-docgen
check-docgen:
tamer: {tools=>build-aux}/asg-ontviz Now that these are actually intended to be used as part of the build, this is a more appropriate location. I originally wrote it as a manual tool. DEV-13708
2023-03-10 15:10:13 -05:00
build-aux/asg-ontviz >/dev/null
tamer: Embed ASG ontology visualization in rustdoc-generated docs There, in-your-face and not hidden in some tools directory. DEV-13708
2023-03-10 14:11:55 -05:00
tamer: tests: System test support This provides a test harness for running shell-based system tests. The first of such tests will be introduced in the following commit. This is done in place of integration tests written in Rust because it will invoke the final binary exactly as the user or build system (using TAMER) will, providing greater confidence. Besides, a lot of things are simply more convenient to do in shell. ...though some of you may debate that. DEV-13708
2023-02-22 22:44:46 -05:00
.PHONY: check-system
check-system: bin
tests/run-tests
.PHONY: check-lint
tamer: Integrate clippy This invokes clippy as part of `make check` now, which I had previously avoided doing (I'll elaborate on that below). This commit represents the changes needed to resolve all the warnings presented by clippy. Many changes have been made where I find the lints to be useful and agreeable, but there are a number of lints, rationalized in `src/lib.rs`, where I found the lints to be disagreeable. I have provided rationale, primarily for those wondering why I desire to deviate from the default lints, though it does feel backward to rationalize why certain lints ought to be applied (the reverse should be true). With that said, this did catch some legitimage issues, and it was also helpful in getting some older code up-to-date with new language additions that perhaps I used in new code but hadn't gone back and updated old code for. My goal was to get clippy working without errors so that, in the future, when others get into TAMER and are still getting used to Rust, clippy is able to help guide them in the right direction. One of the reasons I went without clippy for so long (though I admittedly forgot I wasn't using it for a period of time) was because there were a number of suggestions that I found disagreeable, and I didn't take the time to go through them and determine what I wanted to follow. Furthermore, it was hard to make that judgment when I was new to the language and lacked the necessary experience to do so. One thing I would like to comment further on is the use of `format!` with `expect`, which is also what the diagnostic system convenience methods do (which clippy does not cover). Because of all the work I've done trying to understand Rust and looking at disassemblies and seeing what it optimizes, I falsely assumed that Rust would convert such things into conditionals in my otherwise-pure code...but apparently that's not the case, when `format!` is involved. I noticed that, after making the suggested fix with `get_ident`, Rust proceeded to then inline it into each call site and then apply further optimizations. It was also previously invoking the thread lock (for the interner) unconditionally and invoking the `Display` implementation. That is not at all what I intended for, despite knowing the eager semantics of function calls in Rust. Anyway, possibly more to come on that, I'm just tired of typing and need to move on. I'll be returning to investigate further diagnostic messages soon.
2023-01-12 10:46:48 -05:00
check-lint:
tamer: Makefile.am: cargo clippy: Use active feature flags This was missing `@FEATURES@`, which was causing more compilation than necessary, but also causing clippy to evaluate different code. This also adds RUSTFLAGS, for the same reason of not wanting to recompile. DEV-13708
2023-03-17 10:05:43 -04:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ clippy @FEATURES@
tamer: Integrate clippy This invokes clippy as part of `make check` now, which I had previously avoided doing (I'll elaborate on that below). This commit represents the changes needed to resolve all the warnings presented by clippy. Many changes have been made where I find the lints to be useful and agreeable, but there are a number of lints, rationalized in `src/lib.rs`, where I found the lints to be disagreeable. I have provided rationale, primarily for those wondering why I desire to deviate from the default lints, though it does feel backward to rationalize why certain lints ought to be applied (the reverse should be true). With that said, this did catch some legitimage issues, and it was also helpful in getting some older code up-to-date with new language additions that perhaps I used in new code but hadn't gone back and updated old code for. My goal was to get clippy working without errors so that, in the future, when others get into TAMER and are still getting used to Rust, clippy is able to help guide them in the right direction. One of the reasons I went without clippy for so long (though I admittedly forgot I wasn't using it for a period of time) was because there were a number of suggestions that I found disagreeable, and I didn't take the time to go through them and determine what I wanted to follow. Furthermore, it was hard to make that judgment when I was new to the language and lacked the necessary experience to do so. One thing I would like to comment further on is the use of `format!` with `expect`, which is also what the diagnostic system convenience methods do (which clippy does not cover). Because of all the work I've done trying to understand Rust and looking at disassemblies and seeing what it optimizes, I falsely assumed that Rust would convert such things into conditionals in my otherwise-pure code...but apparently that's not the case, when `format!` is involved. I noticed that, after making the suggested fix with `get_ident`, Rust proceeded to then inline it into each call site and then apply further optimizations. It was also previously invoking the thread lock (for the interner) unconditionally and invoking the `Display` implementation. That is not at all what I intended for, despite knowing the eager semantics of function calls in Rust. Anyway, possibly more to come on that, I'm just tired of typing and need to move on. I'll be returning to investigate further diagnostic messages soon.
2023-01-12 10:46:48 -05:00
tamer: tests: System test support This provides a test harness for running shell-based system tests. The first of such tests will be introduced in the following commit. This is done in place of integration tests written in Rust because it will invoke the final binary exactly as the user or build system (using TAMER) will, providing greater confidence. Besides, a lot of things are simply more convenient to do in shell. ...though some of you may debate that. DEV-13708
2023-02-22 22:44:46 -05:00
.PHONY: check-fmt
Makefile.am (check): Check whether formatting is required Given that developers should be doing TDD and therefore running this target frequently, this has the effect of providing immediate feedback when formatting is needed and outputting a diff. Developers will then quickly understand what changes need to be made to avoid future issues (and can run `cargo fmt` to fix it), at which point they'll rarely ever encounter formatting errors. The original purpose was to ensure pipelines fail when the formatter has not been run.
2019-12-03 13:53:29 -05:00
check-fmt:
tamer: cargo --frozen --offline Cargo's default behavior is unfortunately to issue network calls each time it is invoke in order to check for dependencies updates. This is not only bad for reproducibility and privacy, but it's also a concern for supply chain attacks, since most developers are unaware that this is occurring. Instead, we pin to the lockfile. Installing dependencies can be done with `cargo fetch` and updating dependencies must be explicitly done by the developer, with the lockfile updated.
2021-12-02 11:34:56 -05:00
@CARGO@ +@RUST_TC@ @CARGO_FLAGS@ fmt -- --check
Makefile.am (check): Check whether formatting is required Given that developers should be doing TDD and therefore running this target frequently, this has the effect of providing immediate feedback when formatting is needed and outputting a diff. Developers will then quickly understand what changes need to be made to avoid future issues (and can run `cargo fmt` to fix it), at which point they'll rarely ever encounter formatting errors. The original purpose was to ensure pipelines fail when the formatter has not been run.
2019-12-03 13:53:29 -05:00
Makefile.am (bench): New target The configure script will determine if nightly is required for running benchmarks, because `test` is currently an unstable feature.
2019-12-04 09:57:08 -05:00
bench:
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ @CARGO_BENCH_PRE_FLAGS@ bench $(CARGO_BENCH_FLAGS) @FEATURES@
Makefile.am (bench): New target The configure script will determine if nightly is required for running benchmarks, because `test` is currently an unstable feature.
2019-12-04 09:57:08 -05:00
tamer: Makefile.am (bench-build): New target, default for all Build the benchmarks by default to catch breakages without having to incur the cost of actually running them.
2021-10-08 09:27:56 -04:00
# Build but do not run benches (to ensures we didn't break them)
bench-build:
tamer: Make RUSTFLAGS explicit in the cargo invocation Previously this just exported the variable into the environment, but I'm not comfortable with the lack of visibility that provides; I want to be able to see not only that it's happening, which will help to debug issues, but also when it's _not_ happening so that I know that it needs to be introduced into a configuration at a particular installation site.
2022-12-15 12:12:25 -05:00
RUSTFLAGS="$(RUSTFLAGS)" @CARGO@ +@RUST_TC@ @CARGO_FLAGS@ @CARGO_BENCH_PRE_FLAGS@ build --benches @FEATURES@
tamer: Makefile.am (bench-build): New target, default for all Build the benchmarks by default to catch breakages without having to incur the cost of actually running them.
2021-10-08 09:27:56 -04:00
Makefile.am (check): Check whether formatting is required Given that developers should be doing TDD and therefore running this target frequently, this has the effect of providing immediate feedback when formatting is needed and outputting a diff. Developers will then quickly understand what changes need to be made to avoid future issues (and can run `cargo fmt` to fix it), at which point they'll rarely ever encounter formatting errors. The original purpose was to ensure pipelines fail when the formatter has not been run.
2019-12-03 13:53:29 -05:00
fix: fmt
fmt:
tamer: cargo --frozen --offline Cargo's default behavior is unfortunately to issue network calls each time it is invoke in order to check for dependencies updates. This is not only bad for reproducibility and privacy, but it's also a concern for supply chain attacks, since most developers are unaware that this is occurring. Instead, we pin to the lockfile. Installing dependencies can be done with `cargo fetch` and updating dependencies must be explicitly done by the developer, with the lockfile updated.
2021-12-02 11:34:56 -05:00
@CARGO@ +@RUST_TC@ @CARGO_FLAGS@ fmt
Makefile.am (clean): New target Not sure how I missed this one.
2019-12-10 15:03:06 -05:00
clean-am:
tamer: cargo --frozen --offline Cargo's default behavior is unfortunately to issue network calls each time it is invoke in order to check for dependencies updates. This is not only bad for reproducibility and privacy, but it's also a concern for supply chain attacks, since most developers are unaware that this is occurring. Instead, we pin to the lockfile. Installing dependencies can be done with `cargo fetch` and updating dependencies must be explicitly done by the developer, with the lockfile updated.
2021-12-02 11:34:56 -05:00
@CARGO@ +@RUST_TC@ @CARGO_FLAGS@ clean
.PHONY: fetch
fetch:
@CARGO@ +@RUST_TC@ --locked fetch