Commit Graph

6 Commits

Author SHA1 Message Date
Benjamin Sago
6eb5cee634 Convert manual pages to Markdown
This removes the "raw" man pages and converts them to Markdown, adding a build step using pandoc that converts them.

Having the man pages in Markdown makes them much, much easier to write and keep updated, at the cost of not having the raw formats easily available. Hopefully having the command to generate them in the Justfile will be enough.

It also splits out the EXA_COLORS environment variable into its own page, because it took up just under half of the one for the exa binary.
2020-10-13 20:19:00 +01:00
Benjamin Sago
74d9f1402b Some Clippy fixes 2020-10-10 13:33:50 +01:00
Benjamin Sago
8046980806 Mass version upgrade
This upgrades the versions of everything, including upgrading almost all outdated dependencies.

• number_prefix had some backwards-incompatible changes. It now feels more Rustful, and spells "Mebi" correctly.
• term_grid stopped working when I upgraded it, worryingly, so I reverted it back.
2020-10-10 02:14:35 +01:00
Benjamin Sago
5ca3548bb1 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 01:43:42 +01:00
Benjamin Sago
ee898bef8d Add commands to test feature combinations
Using the cargo-hack command, which now gets installed in the Vagrant environment, there's now an easy way to make sure exa can be built and test with all combinations of features.

There have been times in the past where exa has failed to build without the git feature, and I've just never noticed. This should put a stop to that.
2020-10-10 00:57:20 +01:00
Benjamin Sago
0550faec05 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-10 00:57:04 +01:00