Use Specsheet for the extended tests
This commit changes the way the extended test suite is run.
Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems:
• It stops at the first failure, so if one test fails, you have no idea how many actually failed.
• It also didn't actually show you the diff if one was different, it just checked it.
• It combined stdout and stderr, and didn't test the exit status of exa.
• All the output file names were just whatever I felt like calling the file at the time.
• There is no way to only run a few of the tests — you have to run the whole thing each time.
• There's no feel-good overall view where you see how many tests are passing.
I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time.
The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files.
So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
|
|
|
all: build test xtests
|
|
|
|
|
all-release: build-release test-release xtests-release
|
Replace Makefile with a developmental Justfile
This commit deletes the Makefile, which contained targets to build exa and install it on the local machine, and replaces it with a Justfile, which only contains command to build and test exa.
My reasoning for doing this is as follows:
• exa is increasingly being installed through package managers, rather than built and tested locally, so users are avoiding using the Makefile at all.
• It was a pain to keep up with the correct paths for installing the binary, man pages, and completions, which can vary between OSes. By removing them, the code in this repository need only concern itself with building exa and putting its files in the 'target' directory, simplifying things.
• just is much simpler than make conceptually, which is why I prefer it. It just runs commands, rather than being a complete build system, which we already use Cargo for.
• just has features built-in, such as listing tasks, that we've had to create make targets for.
• exa only needed a Makefile at all because it pre-dates Cargo!
• Other Rust projects seem to be getting along perfectly fine without one.
If I've missed some important reason that makes it worth keeping the Makefile around then please let me know.
2020-10-09 23:47:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# compiles the exa binary
|
|
|
|
|
@build:
|
|
|
|
|
cargo build
|
|
|
|
|
|
|
|
|
|
# compiles the exa binary (in release mode)
|
|
|
|
|
@build-release:
|
|
|
|
|
cargo build --release --verbose
|
|
|
|
|
|
2020-10-09 23:57:20 +00:00
|
|
|
# compiles the exa binary with every combination of feature flags
|
2020-10-10 12:33:50 +00:00
|
|
|
@build-features:
|
2020-10-09 23:57:20 +00:00
|
|
|
cargo hack build --feature-powerset
|
|
|
|
|
|
Replace Makefile with a developmental Justfile
This commit deletes the Makefile, which contained targets to build exa and install it on the local machine, and replaces it with a Justfile, which only contains command to build and test exa.
My reasoning for doing this is as follows:
• exa is increasingly being installed through package managers, rather than built and tested locally, so users are avoiding using the Makefile at all.
• It was a pain to keep up with the correct paths for installing the binary, man pages, and completions, which can vary between OSes. By removing them, the code in this repository need only concern itself with building exa and putting its files in the 'target' directory, simplifying things.
• just is much simpler than make conceptually, which is why I prefer it. It just runs commands, rather than being a complete build system, which we already use Cargo for.
• just has features built-in, such as listing tasks, that we've had to create make targets for.
• exa only needed a Makefile at all because it pre-dates Cargo!
• Other Rust projects seem to be getting along perfectly fine without one.
If I've missed some important reason that makes it worth keeping the Makefile around then please let me know.
2020-10-09 23:47:17 +00:00
|
|
|
|
|
|
|
|
# runs unit tests
|
|
|
|
|
@test:
|
|
|
|
|
cargo test --all -- --quiet
|
|
|
|
|
|
|
|
|
|
# runs unit tests (in release mode)
|
|
|
|
|
@test-release:
|
|
|
|
|
cargo test --release --all --verbose
|
|
|
|
|
|
2020-10-09 23:57:20 +00:00
|
|
|
# runs unit tests with every combination of feature flags
|
2020-10-10 12:33:50 +00:00
|
|
|
@test-features:
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
cargo hack test --feature-powerset -- --quiet
|
2020-10-09 23:57:20 +00:00
|
|
|
|
Replace Makefile with a developmental Justfile
This commit deletes the Makefile, which contained targets to build exa and install it on the local machine, and replaces it with a Justfile, which only contains command to build and test exa.
My reasoning for doing this is as follows:
• exa is increasingly being installed through package managers, rather than built and tested locally, so users are avoiding using the Makefile at all.
• It was a pain to keep up with the correct paths for installing the binary, man pages, and completions, which can vary between OSes. By removing them, the code in this repository need only concern itself with building exa and putting its files in the 'target' directory, simplifying things.
• just is much simpler than make conceptually, which is why I prefer it. It just runs commands, rather than being a complete build system, which we already use Cargo for.
• just has features built-in, such as listing tasks, that we've had to create make targets for.
• exa only needed a Makefile at all because it pre-dates Cargo!
• Other Rust projects seem to be getting along perfectly fine without one.
If I've missed some important reason that makes it worth keeping the Makefile around then please let me know.
2020-10-09 23:47:17 +00:00
|
|
|
|
Use Specsheet for the extended tests
This commit changes the way the extended test suite is run.
Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems:
• It stops at the first failure, so if one test fails, you have no idea how many actually failed.
• It also didn't actually show you the diff if one was different, it just checked it.
• It combined stdout and stderr, and didn't test the exit status of exa.
• All the output file names were just whatever I felt like calling the file at the time.
• There is no way to only run a few of the tests — you have to run the whole thing each time.
• There's no feel-good overall view where you see how many tests are passing.
I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time.
The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files.
So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
|
|
|
# runs extended tests
|
|
|
|
|
@xtests:
|
|
|
|
|
xtests/run.sh
|
|
|
|
|
|
|
|
|
|
# runs extended tests (using the release mode exa)
|
|
|
|
|
@xtests-release:
|
|
|
|
|
xtests/run.sh --release
|
|
|
|
|
|
|
|
|
|
|
2020-10-10 12:33:50 +00:00
|
|
|
# lints the code
|
|
|
|
|
@clippy:
|
|
|
|
|
touch src/main.rs
|
|
|
|
|
cargo clippy
|
|
|
|
|
|
2020-10-10 01:14:35 +00:00
|
|
|
# updates dependency versions, and checks for outdated ones
|
2020-10-24 20:22:07 +00:00
|
|
|
@update-deps:
|
2020-10-10 01:14:35 +00:00
|
|
|
cargo update
|
2020-10-24 20:22:07 +00:00
|
|
|
command -v cargo-outdated >/dev/null || (echo "cargo-outdated not installed" && exit 1)
|
2020-10-10 01:14:35 +00:00
|
|
|
cargo outdated
|
|
|
|
|
|
2020-10-24 20:22:07 +00:00
|
|
|
# lists unused dependencies
|
|
|
|
|
@unused-deps:
|
|
|
|
|
command -v cargo-udeps >/dev/null || (echo "cargo-udeps not installed" && exit 1)
|
|
|
|
|
cargo +nightly udeps
|
|
|
|
|
|
Replace Makefile with a developmental Justfile
This commit deletes the Makefile, which contained targets to build exa and install it on the local machine, and replaces it with a Justfile, which only contains command to build and test exa.
My reasoning for doing this is as follows:
• exa is increasingly being installed through package managers, rather than built and tested locally, so users are avoiding using the Makefile at all.
• It was a pain to keep up with the correct paths for installing the binary, man pages, and completions, which can vary between OSes. By removing them, the code in this repository need only concern itself with building exa and putting its files in the 'target' directory, simplifying things.
• just is much simpler than make conceptually, which is why I prefer it. It just runs commands, rather than being a complete build system, which we already use Cargo for.
• just has features built-in, such as listing tasks, that we've had to create make targets for.
• exa only needed a Makefile at all because it pre-dates Cargo!
• Other Rust projects seem to be getting along perfectly fine without one.
If I've missed some important reason that makes it worth keeping the Makefile around then please let me know.
2020-10-09 23:47:17 +00:00
|
|
|
# prints versions of the necessary build tools
|
|
|
|
|
@versions:
|
|
|
|
|
rustc --version
|
|
|
|
|
cargo --version
|
2020-10-13 19:19:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# builds the man pages
|
|
|
|
|
@man:
|
|
|
|
|
mkdir -p "${CARGO_TARGET_DIR:-target}/man"
|
|
|
|
|
pandoc --standalone -f markdown -t man man/exa.1.md > "${CARGO_TARGET_DIR:-target}/man/exa.1"
|
|
|
|
|
pandoc --standalone -f markdown -t man man/exa_colors.5.md > "${CARGO_TARGET_DIR:-target}/man/exa_colors.5"
|
|
|
|
|
|
|
|
|
|
# builds and previews the main man page (exa.1)
|
|
|
|
|
@man-1-preview: man
|
|
|
|
|
man "${CARGO_TARGET_DIR:-target}/man/exa.1"
|
|
|
|
|
|
|
|
|
|
# builds and previews the colour configuration man page (exa_colors.5)
|
|
|
|
|
@man-5-preview: man
|
|
|
|
|
man "${CARGO_TARGET_DIR:-target}/man/exa_colors.5"
|