| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Reviewed-By: concensus
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Define a specific set of 4 architectures that Morph supports, and only
expose that value to morphologies.
Since GNU triplets are very common we also expose a GNU triplet. Other
morphologies should work out their configuration based on MORPH_ARCH.
This commit also removes the morphlib.util.arch() function, which
detected the machine Morph is running on via 'uname -m'. Morph's
architecture names do not necessarily map to the output of 'uname -m'
so we should not rely on it anywhere.
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
morphlib/bins_tests.py
Reviewed-By: consensus
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allowed values:
staging: build with a staging chroot (default)
test: build with the host's tools
bootstrap: build with the host's tools, and do not include this
chunk in the final stratum artifact
In the past, 'normal mode' has been used to describe building a chunk
with the host's tools. We don't want that mode to ever be used,
because it is a huge hole in reproducability, but we need to keep it
around to avoid making Morph's cmdtest suite depend on Baserock.
Hopefully naming it 'test' should discourage potential abusers.
It is unfortunate that the build tests now take a separate code path
compared to real-world usage of Morph. However, this is necessary to
avoid a circular dependency between Morph's test suite and the
build-essential stratum in Baserock.
We do whole-build testing of Baserock, too, so the 'staging' code path
is still tested outside of Morph. However, testing a staging area
requires populating it with at minimum a working shell, and this is a
bit too complex to go in Morph's test suite.
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
Allowing differences causes only confusion. Whether or not the 'name'
field should surive at all is up for debate: it's very useful when
seeing the contents of the morphology out of context (e.g. in
documentation or pastebins), but is that worth the extra effort?
|
|
|
|
|
| |
This can go away when we have made a release with yaml in it, and its
staging filler.
|
|
|
|
|
| |
Tests are currently broken, one because invalid JSON
can be valid YAML, and coverage is incomplete.
|
|
|
|
|
|
|
| |
This simply increases the verbosity of the operations which
are done against the remote artifact cache. It should result in some
progress messages if you build with --verbose set and you're mostly
getting stuff from your remote artifact cache (Trove).
|
|
|
|
|
| |
armv5 and armv7 are different enough to be a problem, so specify
which particular arm sub-architecture we currently support.
|
|
|
|
|
| |
This allows a few more diagnostics of what went wrong when the error
is inside the baserock:morphs repository.
|
|
|
|
| |
Rename "sources" field of stratum morphologies to "chunks".
|
|
|
|
|
| |
This provides much better performance in cases where most of the
repos do not have a .morph included.
|
|
|
|
|
|
|
| |
The cost of one git ls-tree call is roughly the same as one
git cat-file call. Therefore, when autodetecting the build system,
it is much faster to list the tree once and then search for the
required files than to call git cat-file for every possible one.
|
|
|
|
|
|
| |
It turns out that BaseException.message is deprecated, and str(e) is
a better way of achieving that. This makes the unit tests not spew out
a deprecation warning.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
morphlib/morphologyfactory.py
morphlib/morphologyfactory_tests.py
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
git://roadtrain.codethink.co.uk/baserock/morph
Merged with a tweak to the layout, since the code style's display
width is 79 characters, rather than 80.
|
| |/ |
|
|/
|
|
|
|
|
|
|
| |
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 way we can have one place in the code where we determine what
artifacts get built from a specific morphology, rather than spreading
the information around the code base.
From now on, everything is supposed to use the builds_artifacts attribute
to get the list of artifacts. ArtifactResolver has been changed to do that.
Some of the tests are now a bit messier, and should really be changed
to create Morphology objects using MorphologyFactory, but that's a change
for another day.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I think morphologies should be verified closer to where they are
created, not when they are traversed, since this verification would
be useful in more code paths.
This is in morphologyfactory, rather than Morphology itself, since
it may be useful to be able to create morphologies without checking,
such as in unit tests.
|
|
|
|
|
|
|
|
|
|
| |
Detecting the build system is managed by it asking if any files exist
detecting if the file exists is done with a callback function.
This callback can use cat-file.
If list_files existed this could be more efficient as it would not
require the files to be read from the remote server and it only needs
to be one round-trip
|
|
|
|
|
| |
There are cases where we would not need a remote cache, so it
should be able to operate without one.
|
|
|