employer
/
tame
1
0
Fork 0
Code Packages Releases Activity
tame/tamer/configure.ac

158 lines
6.3 KiB
Plaintext
Raw Normal View History

TAMER: Initial commit
2019-11-14 16:43:07 -05:00
# For use by automake and autoconf
#
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/>.
##
m4_include([build-aux/m4/ax_compare_version.m4])
# version string is dynamically generated
m4_define([ver], m4_esyscmd(build-aux/vergen))
m4_if(ver, [], [m4_exit(1)])
AC_INIT([tame], [ver], [dev@lovullo.com])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE([foreign])
# provide more granular version numbers based on the version string, using
# the format MAJOR.MINOR.REV[-SUFFIX], where SUFFIX can itself contain
# dashes (and often will)
m4_define([ver_split],
m4_split(
patsubst(AC_PACKAGE_VERSION, [^\([^-]+\)-], [\1.]),
[\.]))
AC_SUBST(MAJOR, m4_argn(1, ver_split))
AC_SUBST(MINOR, m4_argn(2, ver_split))
AC_SUBST(REV, m4_argn(3, ver_split))
AC_SUBST(SUFFIX, m4_argn(4, ver_split))
AC_ARG_VAR([CARGO], [Rust Cargo executable])
AC_CHECK_PROGS(CARGO, [cargo])
test -n "$CARGO" || AC_MSG_ERROR([cargo not found])
tamer: Support nightly Rust toolchain pinning I had never intended to avoid pinning nightly. This is an unfortunate thing to have to do---require a _specific_ version of a compiler to build your software; it's madness. But the unstable features utilized by TAMER (as rationalized in `src/lib.rs`) are still worth the effort. It's not _actually_ that case that we need a specific version of the compiler, granted; this is outlined in `rust-toolchain.toml`'s rationale. You should look there for more information; my approach still utilizes explicit channels via cargo. Unfortunately, I had hard-coded it previously, putting me in a bit of a bind an unable to override the behavior without modifying the software. The reason for this change is that `adt_const_params` has a BC break involving the introduction of `ConstParamTy`. This is only the second time I've been bitten by a nightly BC break; the other was the renaming of `int_log`'s API, as mentioned in 709291b1073bf0bb7898d2437fbeff5bef18820b. This pinning will in fact mitigate those future issues---TAMER will be able to resolve the issue at its leisure, and will further be able to continue to build earlier commits in the future by simply re-bootstrapping with the committed nightly version. If you're curious of my rationale for wanting to inhibit toolchain downloading during build, or use system libraries, have a look at GNU Guix's approach to building software safely and reproducibly. In particular, dependencies are also built from source (rather than downloading binaries from external sources), and builds take place in network-isolated containers. The `TAMER_RUST_TOOLCHAIN` configure parameter is meant to facilitate these situations by giving more flexibility to packagers. DEV-14476
2023-06-05 15:58:26 -04:00
# Derive the expected nightly version from `rust-toolchain.toml` and
# configure the build system to use that version explicitly for each cargo
# invoation in the Makefile.
#
# See rust-toolchain.toml for information about this process. Note that
# this file will only trigger an auto-update if it is actually used to
# derive the version (if TAMER_RUST_TOOLCHAIN is _not_ used).
AC_ARG_VAR([TAMER_RUST_TOOLCHAIN],
[Rust toolchain channel to use in place of rust-toolchain.toml contents])
AC_MSG_CHECKING([toolchain channel])
AS_IF([test -n "$TAMER_RUST_TOOLCHAIN"],
[AC_MSG_RESULT([$TAMER_RUST_TOOLCHAIN (from TAMER_RUST_TOOLCHAIN)])
AC_SUBST(RUST_TC, [$TAMER_RUST_TOOLCHAIN])],
[rust_channel=$($AWK -F '[[ "]]' '$1=="channel" { print $4 }' rust-toolchain.toml)
AS_IF([test -n "$rust_channel"],
[AC_MSG_RESULT([$rust_channel (from rust-toolchain.toml)])
AC_SUBST([RUST_TC], [$rust_channel])],
[AC_MSG_RESULT([missing (from both rust-toolchain.toml and TAMER_RUST_TOOLCHAIN)])
AC_MSG_ERROR([rust-toolchain.toml is missing or does not contain channel])])
AC_SUBST([CONFIG_STATUS_DEPENDENCIES], rust-toolchain.toml)])
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
# There is no reason the build should _ever_ access the network.
# This both helps with reproducibility and helps to mitigate supply chain
# attacks by requiring developers to explicitly indicate their intent to
# fetch a network resource (by invoking cargo manually).
AC_SUBST([CARGO_FLAGS], "--frozen --offline")
tamer: Support nightly Rust toolchain pinning I had never intended to avoid pinning nightly. This is an unfortunate thing to have to do---require a _specific_ version of a compiler to build your software; it's madness. But the unstable features utilized by TAMER (as rationalized in `src/lib.rs`) are still worth the effort. It's not _actually_ that case that we need a specific version of the compiler, granted; this is outlined in `rust-toolchain.toml`'s rationale. You should look there for more information; my approach still utilizes explicit channels via cargo. Unfortunately, I had hard-coded it previously, putting me in a bit of a bind an unable to override the behavior without modifying the software. The reason for this change is that `adt_const_params` has a BC break involving the introduction of `ConstParamTy`. This is only the second time I've been bitten by a nightly BC break; the other was the renaming of `int_log`'s API, as mentioned in 709291b1073bf0bb7898d2437fbeff5bef18820b. This pinning will in fact mitigate those future issues---TAMER will be able to resolve the issue at its leisure, and will further be able to continue to build earlier commits in the future by simply re-bootstrapping with the committed nightly version. If you're curious of my rationale for wanting to inhibit toolchain downloading during build, or use system libraries, have a look at GNU Guix's approach to building software safely and reproducibly. In particular, dependencies are also built from source (rather than downloading binaries from external sources), and builds take place in network-isolated containers. The `TAMER_RUST_TOOLCHAIN` configure parameter is meant to facilitate these situations by giving more flexibility to packagers. DEV-14476
2023-06-05 15:58:26 -04:00
# This is the version of Rust that would be required if we were not
# utilizing nightly features. This serves as a lower version bound, whereas
# the nightly check above serves as an upper bound.
tamer: Rust v1.{68=>70}: Stabalized nonzero_min_max and is_some_and These two features have been stabalized in Rust 1.70.
2023-04-12 11:42:01 -04:00
rustc_ver_req=1.70
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
AC_CHECK_PROGS(RUSTC, [rustc])
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
AC_MSG_CHECKING([rustc $RUST_TC version >= $rustc_ver_req])
rustc_version=$("$RUSTC" "+$RUST_TC" --version | cut -d' ' -f2)
tamer: Support nightly Rust toolchain pinning I had never intended to avoid pinning nightly. This is an unfortunate thing to have to do---require a _specific_ version of a compiler to build your software; it's madness. But the unstable features utilized by TAMER (as rationalized in `src/lib.rs`) are still worth the effort. It's not _actually_ that case that we need a specific version of the compiler, granted; this is outlined in `rust-toolchain.toml`'s rationale. You should look there for more information; my approach still utilizes explicit channels via cargo. Unfortunately, I had hard-coded it previously, putting me in a bit of a bind an unable to override the behavior without modifying the software. The reason for this change is that `adt_const_params` has a BC break involving the introduction of `ConstParamTy`. This is only the second time I've been bitten by a nightly BC break; the other was the renaming of `int_log`'s API, as mentioned in 709291b1073bf0bb7898d2437fbeff5bef18820b. This pinning will in fact mitigate those future issues---TAMER will be able to resolve the issue at its leisure, and will further be able to continue to build earlier commits in the future by simply re-bootstrapping with the committed nightly version. If you're curious of my rationale for wanting to inhibit toolchain downloading during build, or use system libraries, have a look at GNU Guix's approach to building software safely and reproducibly. In particular, dependencies are also built from source (rather than downloading binaries from external sources), and builds take place in network-isolated containers. The `TAMER_RUST_TOOLCHAIN` configure parameter is meant to facilitate these situations by giving more flexibility to packagers. DEV-14476
2023-06-05 15:58:26 -04:00
AS_IF([test -z "$rustc_version"],
[AC_MSG_ERROR([
failed to execute rustc with toolchain $RUST_TC (see above for error message)
- if the above toolchain is not found, try running `bootstrap`])])
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
AX_COMPARE_VERSION([$rustc_version], [ge], [$rustc_ver_req],
[AC_MSG_RESULT([yes ($rustc_version)])],
tamer: Support nightly Rust toolchain pinning I had never intended to avoid pinning nightly. This is an unfortunate thing to have to do---require a _specific_ version of a compiler to build your software; it's madness. But the unstable features utilized by TAMER (as rationalized in `src/lib.rs`) are still worth the effort. It's not _actually_ that case that we need a specific version of the compiler, granted; this is outlined in `rust-toolchain.toml`'s rationale. You should look there for more information; my approach still utilizes explicit channels via cargo. Unfortunately, I had hard-coded it previously, putting me in a bit of a bind an unable to override the behavior without modifying the software. The reason for this change is that `adt_const_params` has a BC break involving the introduction of `ConstParamTy`. This is only the second time I've been bitten by a nightly BC break; the other was the renaming of `int_log`'s API, as mentioned in 709291b1073bf0bb7898d2437fbeff5bef18820b. This pinning will in fact mitigate those future issues---TAMER will be able to resolve the issue at its leisure, and will further be able to continue to build earlier commits in the future by simply re-bootstrapping with the committed nightly version. If you're curious of my rationale for wanting to inhibit toolchain downloading during build, or use system libraries, have a look at GNU Guix's approach to building software safely and reproducibly. In particular, dependencies are also built from source (rather than downloading binaries from external sources), and builds take place in network-isolated containers. The `TAMER_RUST_TOOLCHAIN` configure parameter is meant to facilitate these situations by giving more flexibility to packagers. DEV-14476
2023-06-05 15:58:26 -04:00
[AC_MSG_RESULT([no ($rustc_version)])])
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
AC_ARG_VAR([CARGO_BUILD_FLAGS],
[Flags to be passed to `cargo build' when invoked via Make])
tamer: RUSTFLAGS support Primarily intended for `-C target-cpu=native`.
2022-12-14 19:56:57 -05:00
AC_ARG_VAR([RUSTFLAGS],
[Flags to be passed to `rustc' when invoked via Make])
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: Rust 1.{42=>48}.0 for stable intra-doc links without nightly
2021-06-21 13:10:00 -04:00
# All currently-used doc features are stable (this used to be used for
# intra-doc links)
AC_SUBST([CARGO_DOC_FLAGS], [])
Makefile.am (doc, html): Use intra_rustdoc_links This is enabled by default in nightly, and is not available at all in stable. Considering the PITA that it will be to go back and rewrite docs to use the new format, and how important of a feature this is, we will just make use of it now.
2019-12-04 11:18:12 -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
# The `test` feature is required for benchmarking. If unavailable, then
# it's still an unstable feature and we'll need to use nightly. We don't
# check for nightly here, though---if it's missing, then cargo will tell the
# user what to do.
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
AC_MSG_CHECKING([`test` feature support on $RUST_TC])
AS_IF(["$RUSTC" "+$RUST_TC" --crate-type lib build-aux/bench_check.rs &>/dev/null],
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
[AC_MSG_RESULT(available)],
[AC_MSG_RESULT([no (nightly required)])
tamer: Makefile.am (CARGO_BENCH_FLAGS): New env var
2021-08-19 16:43:14 -04:00
AC_SUBST([CARGO_BENCH_PRE_FLAGS], [+nightly])])
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
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
# Cargo commands may be available but not necessarily installed for the
# active toolchain. Let's check that.
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
AC_MSG_CHECKING([whether cargo-fmt is available on $RUST_TC])
AS_IF([cargo "+$RUST_TC" fmt --help &>/dev/null],
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
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
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
cargo "+$RUST_TC" fmt --help # run again so user can see output
AC_MSG_ERROR([missing cargo-fmt on $RUST_TC])])
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 (doc, html): Use intra_rustdoc_links This is enabled by default in nightly, and is not available at all in stable. Considering the PITA that it will be to go back and rewrite docs to use the new format, and how important of a feature this is, we will just make use of it now.
2019-12-04 11:18:12 -05:00
# Cargo commands may be available but not necessarily installed for the
# active toolchain. Let's check that.
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
AC_MSG_CHECKING([whether cargo-doc is available on $RUST_TC])
AS_IF([cargo "+$RUST_TC" $CARGO_DOC_FLAGS doc --help &>/dev/null],
Makefile.am (doc, html): Use intra_rustdoc_links This is enabled by default in nightly, and is not available at all in stable. Considering the PITA that it will be to go back and rewrite docs to use the new format, and how important of a feature this is, we will just make use of it now.
2019-12-04 11:18:12 -05:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
configure.ac: Missing cargo-doc error=>warning Documentation does not need to be built by most users, who are simply trying to bootstrap the system.
2020-03-05 11:16:15 -05:00
# run again so user can see output
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
cargo "+$RUST_TC" $CARGO_DOC_FLAGS doc --help 2>&1 | sed 's/^.*: //'
AC_MSG_WARN([missing cargo-doc on $RUST_TC])
configure.ac: Missing cargo-doc error=>warning Documentation does not need to be built by most users, who are simply trying to bootstrap the system.
2020-03-05 11:16:15 -05:00
AC_MSG_WARN([`make html` will not work])])
Makefile.am (doc, html): Use intra_rustdoc_links This is enabled by default in nightly, and is not available at all in stable. Considering the PITA that it will be to go back and rewrite docs to use the new format, and how important of a feature this is, we will just make use of it now.
2019-12-04 11:18:12 -05:00
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
AC_MSG_CHECKING([whether cargo-clippy is available on $RUST_TC])
AS_IF([cargo "+$RUST_TC" clippy --help &>/dev/null],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
cargo "+$RUST_TC" clippy --help # run again so user can see output
AC_MSG_ERROR([missing cargo-fmt on $RUST_TC])])
tamer: configure.ac: Configure-time feature flags (via Cargo)
2021-07-23 10:16:44 -04:00
AC_ARG_VAR([FEATURES],
[Cargo features flags for TAMER, comma-delimited])
tamer: configure.ac: conf.sh: New configuration file The intent is to source this in shell scripts, like tests. This exposes feature flags to shell scripts, but it doesn't do so in quite the same way that Rust does---it doesn't apply the dependencies. While this isn't needed now, it does make me a little uncomfortable, and so I may take a different approach in the future. DEV-13708
2023-02-22 21:55:51 -05:00
AC_SUBST([FEATURES_RAW], [])
tamer: configure.ac: Configure-time feature flags (via Cargo)
2021-07-23 10:16:44 -04:00
test -z "$FEATURES" || {
AC_MSG_RESULT([requested features: $FEATURES])
tamer: configure.ac: conf.sh: New configuration file The intent is to source this in shell scripts, like tests. This exposes feature flags to shell scripts, but it doesn't do so in quite the same way that Rust does---it doesn't apply the dependencies. While this isn't needed now, it does make me a little uncomfortable, and so I may take a different approach in the future. DEV-13708
2023-02-22 21:55:51 -05:00
FEATURES_RAW="$FEATURES"
tamer: configure.ac: Configure-time feature flags (via Cargo)
2021-07-23 10:16:44 -04:00
FEATURES="--features $FEATURES"
}
tamer: asg::graph::object::xir: Initial rate element reconstruction This extends the POC a bit by beginning to reconstruct rate blocks (note that NIR isn't producing sub-expressions yet). Importantly, this also adds the first system tests, now that we have an end-to-end system. This not only gives me confidence that the system is producing the expected output, but serves as a compromise: writing unit or integration tests for this program derivation would be a great deal of work, and wouldn't even catch the bugs I'm worried most about; the lowering operation can be written in such a way as to give me high confidence in its correctness without those more granular tests, or in conjunction with unit or integration tests for a smaller portion. DEV-13708
2023-02-22 23:03:42 -05:00
# Other programs used by scripts
AC_CHECK_PROGS(XMLLINT, [xmllint])
test -n "$XMLLINT" || AC_MSG_ERROR([xmllint not found])
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
AC_CHECK_PROGS(DOT, [dot])
test -n "$DOT" || AC_MSG_ERROR([Graphviz dot not found])
tamer: configure.ac: conf.sh: New configuration file The intent is to source this in shell scripts, like tests. This exposes feature flags to shell scripts, but it doesn't do so in quite the same way that Rust does---it doesn't apply the dependencies. While this isn't needed now, it does make me a little uncomfortable, and so I may take a different approach in the future. DEV-13708
2023-02-22 21:55:51 -05:00
AC_CONFIG_FILES([Makefile conf.sh])
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
AC_OUTPUT