| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can simplify our Makefiles a bit by moving some things into a
library file. So far, I've done this for non-component-specific
macros, and inference rules.
Some tar2ext4 rules used a temporary file for the tar2ext4 invocation,
and then moved the file into place when it was done, to prevent a
half-built image sticking around if tar2ext4 died. According to
POSIX, make should clean up any targets that didn't finish building if
it's interrupted, so we should only end up with a half-built image if
tar2ext4 crashes, e.g. due to running out of disk space. I think we
should just ignore that possibility, since otherwise we'd have to
write annoying make rules using temporary file names for every target,
and if it does happen recovery is just a make clean away.
With this, I've also made a small reorganisation. I got rid of the
"nix" directory and created a "lib" directory, where I put
eval-config.nix and the new common.mk file, since both are library
code. checks.nix isn't really a library though, so I moved it into
the "release" directory, since the only reference to it is in
release.nix.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I introduced the global src attribute, I broke custom
configurations, since they wouldn't be passing that key in, and nor
should they. To allow for non-customisable globals like src, we need
to separate them from config. Here, I've modified eval-config.nix to
take a callback, so that it can provide multiple attributes, and
handle command line arguments itself so that doesn't need to be in
every entry point any more. This gives us an interface similar to the
NixOS module system's, where a variety of globals are available that
can be pulled out of the passed attribute set as required, but with
the additional advantage that files are usable directly from
nix-build, and support command line arguments.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: 0149885 ("nix: centralise source cleaning")
|
| |
|
|
|
|
|
|
|
|
| |
This will allow people who just want to test one patch series to skip
an annoying setup process. To be honest, I'm not sure if it's worth
keeping the documentation about manually setting it up. I'm worried
it'll just confuse people. But I'm keeping it for now. We can remove
it later.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, a file called "config.nix" in the root of the Spectrum
repository will be read if it exists. That file should contain an
attribute set. Currently, only a "pkgs" key is supported, which
allows specifying a custom package set that will be used throughout
the Spectrum Nix files. This will allow us to provide configuartion
options for people who want to build Spectrum in ways that are
probably not suitable for upstreaming.
For example, using the "pkgs" config option I'm introducing here, it
would be possible to use an overlay to patch individual components,
like so:
{
pkgs = import <nixpkgs> {
overlays = [
(final: super: {
weston = super.weston.overrideAttrs ({ patches ? [], ... }: {
patches = patches ++ [
path/to/weston.patch
];
});
})
];
};
}
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20220831093727.282797-1-hi@alyssa.is>
Reviewed-by: Ville Ilvonen <ville.ilvonen@unikie.com>
Tested-by: José Pekkarinen <jose.pekkarinen@unikie.com>
|
| | |
|
| |
|
|
|
| |
There's nothing to build at the top-level, but we can still benefit
from a shell.nix for linters and stuff like reuse.
|
| | |
|
| |
|
|
|
|
| |
This is a bit more annoying to use because it requires a privileged
user to have set up some tap devices, but it's useful for testing
virtio-console.
|
| |
|