A modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth — and committed to doing right by its community
https://lix.systems
jade
b62cc7b361
Context: we have include paths that are "types.hh" and similarly common
names. We currently have these compatibly available as
"lix/libutil/types.hh" externally but *not yet internally*. This is
because we don't have any way for the src directory to appear as
`"lix/"` from inside of Lix: the lix/ include directory is created by
the install process.
The goal of this whole thing is to make it clearer which component of
Lix that files are a part of, which should hopefully help at least a
little bit to new developers. One disadvantage of un-mixing these is
that it will cause some API changes if we ever move a file between
libraries, but that is not very common, and we don't care that much
about external API users.
This was planned for a while and is why we have a FixIncludes check to
begin with.
Personally I don't see a great benefit in rearranging our source code,
and in fact, it would probably be counterproductive:
- Moving the includes into a separate `include/` directory would just
make developers have to deal with more directories, when we can
already generate the desired layout through the build process.
- This would also decouple the .cc and .hh files which currently
conventionally have each others' definitions and declarations
respectively, right next to each other, making it easier for them to
feel decoupled and diverge.
Content: Add ../include as an include directory so that lix/ in include
paths will resolve to src/ within Lix itself, just as it does externally
today. This prepares for a further series of commits applying the actual
change to each library one-by-one by accepting both include versions at
once.
This could have been done with ../ and a symlink called lix, but we
would like to not accept libexpr/foo.hh internally for it would be
broken externally, so we need an otherwise empty directory for the
include.
Change-Id:
|
||
|---|---|---|
| .github | ||
| bench | ||
| contrib | ||
| doc | ||
| maintainers | ||
| meson | ||
| misc | ||
| nix-support | ||
| perl | ||
| releng | ||
| scripts | ||
| src | ||
| subprojects | ||
| tests | ||
| .clang-format | ||
| .clang-tidy | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .envrc | ||
| .gitignore | ||
| .mailmap | ||
| .this-is-lix | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| default.nix | ||
| docker.nix | ||
| flake.lock | ||
| flake.nix | ||
| justfile | ||
| meson.build | ||
| meson.options | ||
| package.nix | ||
| README.md | ||
| shell.nix | ||
| treefmt.toml | ||
| version.json | ||
Lix
Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.
Read more about us at https://lix.systems.
Installation
On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
For systems that already have a Nix implementation installed, such as NixOS systems, read our install page
Building And Developing
See our Hacking guide in our manual for instruction on how to to set up a development environment and build Lix from source.
Additional Resources
License
Lix is released under LGPL-2.1-or-later.