| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
This was used by artifacts to tell what they should put in their path,
based on what prefixes were used earlier.
This implementation didn't handle recursive deps, and it was trivial to
open-code it at the call-site, so it is no longer useful.
|
|
|
|
|
| |
This means we can avoid having to rewrite everything immediately after
the fields moved.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata_version is for when the format of the /baserock metadata files
changes.
This means it would make sense for it to either live with the code for
generating the metadata, or the cache key code so it lives with the rest
of the compatibility values.
Since the code for generating the metadata isn't in a nice module
anywhere, I've put it in the cachekeycomputer module.
|
|
|
|
|
| |
This helps debugging issues with rule matching, since SplitRules can be
print-statemented
|
|
|
|
|
|
|
|
|
|
| |
Parts of the morphology go into the name of the staging area, so it
helps to convert them into a str, so later attempts to join it with
another string don't result in a unicode string.
pyfilesystem insists that file paths must be unicode. It is incorrect,
but we passed something unicode compatible in in the first place, so we
can get away with converting it back to a bytestring.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Morph no longer supports setting the prefix using the --prefix
argument / setting. This was only used in tests and during bootstrap.
If a chunk build-depends on a chunk within a stratum which has
a custom prefix, that prefix is appended to the PATH in the build
environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reorganise the build_artifact() and build_artifacts() functions to
allow more complex work when setting up chunk builds in
build_artifact().
The staging area now holds the BuildEnvironment object (the
environment variables that should be set during build). This makes sense
because all build commands should be run inside the staging area and
therefore through the StagingArea object.
The BuildEnvironment object is now considered immutable after it is
created. The environment is used in cache key computation when
computing what artifacts are required; if it changes after that point
we risk either computing different artifact keys for the same artifact
or missing data in the cache key that should be included in the hash.
Better to force changes into a separate 'extra_env' variable.
|
|
|
|
| |
Reported-By: Sam Thursfield
|
|
|
|
|
| |
The artifact's build dependencies replace the build order graph
from previously.
|
|
|
|
|
|
|
|
|
| |
This was done with the aid of the pep8 script, available by running
`easy_install pep8`.
It may be worth making this part of ./check, but that will require
putting pep8 into the development tools stratum.
This should be easy, given pep8 has no external dependencies.
|
|
|
|
| |
This is probably excessively large right now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this commit, the ArtifactResolver no longer computes the cache keys
when creating Artifact objects. This will have to happen as a
post-resolving step (e.g. prior to building or checking whether a local
or remote artifact cache has any of the resolved artifacts).
The CacheKeyComputer now takes an Artifact object and computes the cache
keys using its dependencies.
BuildGraph is no longer needed for the CacheKeyComputer unit tests.
|
|
|
|
|
|
|
| |
The __str__() method returns "x|y|z|a" where x is the repo, y is the
original ref, z is the morphology filename and a is the name of the
artifact. This is a consistent extension of the str() implementation
of Source, which returns just "x|y|z".
|
| |
|
| |
|
|
|
|
|
|
|
| |
This class takes a CacheKeyComputer and a SourcePool, analyses the
sources and their dependencies and creates a list of artifacts
(represented by Artifact objects) that would be created when
building sources in the pool.
|
|
An Artifact represents a thing that morph has built. An example would
be eglibc-runtime which morph may have built from the eglibc chunk
morphology. Another example would be a ready-to-use system image.
The LocalArtifactCache allows to store build artifacts in a local
directory. Users of this class can ask it whether it has a certain
artifact. They can also optain an I/O handle to read the artifact data
from.
In addition to just abstracting the way artifacts are stored,
LocalArtifactCache also allows to store and retrieve metadata for
(a) artifacts and (b) sources (the latter requires a cache key to
be provided to the LocalArtifactCache).
|