this was never actually used, and bad design in the first place—why
should a bad resource be put back into the idle pool? just drop it.
Change-Id: Idab8774bee19dadae0209d404c4fb86dd4aeba1e
if a scope owning a resource does not gracefully drop that resource
while handling exceptions from deeper down the call stack we should
assume the resource is invalid state and drop it. currently it *is*
true that such cases do not cause resources to be freed, but thanks
to validator misuses this has so far not caused any larger problem.
Change-Id: Ie4f91bcd60a64d05c5ff9d22cc97954816d13b97
Perl has an env hook[1]. Passing the paths manually without putting them
in buildInputs is harder to understand, plays less nicely with dev
shells, and is less build-generic.
Produced identical output on my x86_64-linux machine, and on my
aarch64-darwin machine was identical save for the derivation output path
which gets embedded into the .dylib Mach-O.
Change-Id: Ib313caa5a6f0b0e3154ce6f05379033920d0d290
this notably does *not* install the `nix3-manpages` manpage the old
system generated, mostly because that page was empty and just a bug
with a coat of documentation paint.
Change-Id: I7a4248a72e7bb5e0cc925a6311a33b6b72589569
we'll want to use these for the meson builds, and probably eventually
rewrite them in something that isn't plain shell. diffoscope confirms
that out/share and doc/share are equal before and after these changes
Change-Id: I49aa418fc8615cad86d67328e08c28a7405ec952
The big ones here are `trim-trailing-whitespace` and `end-of-file-fixer`
(which makes sure that every file ends with exactly one newline
character).
Change-Id: Idca73b640883188f068f9903e013cf0d82aa1123
We got confused what formals did and had to briefly figure it out. We
should just have docs, so these are some.
Change-Id: If3e794a401e69d022785cbfa0b0c2e2284f41f58
the autoconf build system defaults to /nix/var, not /nix/var/nix. the
latter is only used in libstore, so we'll move the extra segment there.
Change-Id: Idfbc988ee302355982abdcd51d6d7b5d5d661c0d
Without this, the Meson setup won't bail out if nlohmann_json is
missing, leading to subpar DX (and maybe worse, but I'm not entirely
sure).
Change-Id: I5913111060226b540dcf003257c99a08e84da0de
one headers (args/root.hh) was simply missing, and the generated headers
were not installed. not all of them *should* be installed either, only a
select few (and sadly this needs a custom target for each one, it seems)
Change-Id: I37b25517895d0e5e521abc1202fa65624de57ed1
sometimes these fail with timeouts on loaded machines. let's up the
timeouts until we can pull the tests apart to more reasonable sizes
Change-Id: I2dfff2183cc1f3ff5e6107f43748ac046fe00d05
- Enable parallel builds by default (and allow using environment
variables to override `make` variables)
- Hopefully we can get rid of this once we have Meson
- Set `GTEST_BRIEF=1`
- This only shows failed tests, instead of listing every test on its
own line.
```
$ GTEST_BRIEF=1 make check
[==========] 328 tests from 15 test suites ran. (37 ms total)
[ PASSED ] 328 tests.
```
Change-Id: Id8103a8f24a9681be2be87e1b4df6fd5fdd7e4fd
Functional tests can be run with
`meson test -C build --suite installcheck`.
Notably, functional tests must be run *after* running `meson install`
(Lix's derivation runs the installcheck suite in installCheckPhase so it
does this correctly), due to some quirks between Meson and the testing
system.
As far as I can tell the functional tests are meant to be run after
installing anyway, but unfortunately I can't transparently make
`meson test --suite installcheck` depend on the install targets.
The script that runs the functional tests, meson/run-test.py, checks
that `meson install` has happened and fails fast with a (hopefully)
helpful error message if any of the functional tests are run before
installing.
TODO: this change needs reflection in developer documentation
Change-Id: I8dcb5fdfc0b6cb17580973d24ad930abd57018f6
This was achieved by running maintainers/buildtime_report.sh on the
build directory of a meson build, then asking "why the heck is json
eating our build times", and strategically moving the json using bits
out of widely included headers.
It turns out that putting literally any metrics whatsoever into the
build had immediate and predictable results.
Results are 1382.5s frontend time -> 1175.4s frontend time, back end
time approximately invariant.
Related: lix-project/lix#159
Change-Id: I7edea95c8536203325c8bb4dae5f32d727a21b2d
I didn't enable this by default for clang due to making the build time
10% worse or so. Unfortunate, but tbh devs for whom 10% of build time is
not *that* bad should probably simply enable this.
Change-Id: I8d1e5b6f3f76c649a4e2f115f534f7f97cee46e6
hacking changelog-d to support not just github but also forgejo and
gerrit is a lot more complicated than it's worth, even moreso since
the entire thing can just as well be done with ~60 lines of python.
this new script is also much cheaper to instantiate (being python),
so having it enabled in all shells is far less of a hassle.
we've also adjusted existing release notes that referenced a gerrit
cl to auto-link to the cl in question, making the diff a bit bigger
closes lix-project/lix#176
Change-Id: I8ba7dd0070aad9ba4474401731215fcf5d9d2130
Once this commit lands, we are even more visible in analytics FWIW.
Change-Id: Id7e0c162315d0f191edbea9cb5fb82ce363704b9
Signed-off-by: Raito Bezarius <raito@lix.systems>
eldritch horrors
Rebecca Turner
Qyriad
jade
Jade Lovelace
Winter Cute
raito
Ilya K