summaryrefslogtreecommitdiff
path: root/clusters/sdk-example-cluster.morph.in
diff options
context:
space:
mode:
authorSam Thursfield <sam.thursfield@codethink.co.uk>2016-04-11 17:57:57 +0100
committerSam Thursfield <sam.thursfield@codethink.co.uk>2016-04-15 18:58:27 +0100
commit25041b86249fe763fd4171e2ab1aca535b3eb14f (patch)
treeacaa7a5268ff1aa796d1ca1a519cc0ddc4ac3d5c /clusters/sdk-example-cluster.morph.in
parent467bb8299ddc051855acb2093fd371e3423a0515 (diff)
downloaddefinitions-sam/easy-templating.tar.gz
Add a simple templating system to Baserock definitionssam/easy-templating
This is currently independent of the actual definitions format. The 'configure' tool generates actual .morph files from .morph.in files, and build tools then operate on these generated .morph files.t This is largely untested and no doubt broken!
Diffstat (limited to 'clusters/sdk-example-cluster.morph.in')
-rw-r--r--clusters/sdk-example-cluster.morph.in46
1 files changed, 46 insertions, 0 deletions
diff --git a/clusters/sdk-example-cluster.morph.in b/clusters/sdk-example-cluster.morph.in
new file mode 100644
index 00000000..b1096423
--- /dev/null
+++ b/clusters/sdk-example-cluster.morph.in
@@ -0,0 +1,46 @@
+name: sdk
+kind: cluster
+description: |
+ An example of creating a cross-compile SDK for an embedded Baserock system.
+
+ This cluster demonstrates how you can use the 'sdk' write extension to
+ produce a cross-compile SDK tarball for an Baserock applicance. In this
+ example the system is assumed to run on ARMv7, and the SDK is built to
+ run on any x86_32 GNU/Linux system.
+
+ The SDK is a Baserock system itself, containing just 'build-essential' and a
+ 'cross-toolchain' stratum. The SDK system also includes the target
+ appliance's system, as a 'subsystem', so that the libraries and headers are
+ available when building.
+
+ This cluster deploys the SDK system using the 'sdk' write extension, which
+ produces a tarball with a small shell header. When the shell header is
+ executed, and passed a directory name on the commandline, it extracts the SDK
+ to that path and patches the binaries so that they execute correctly from
+ that directory.
+
+ Deploying the applicate system artifact to the target device should be
+ done with a separate cluster morphology, because you will often want to
+ do this without rebuilding the SDK.
+
+ You must build each system with `morph build` before deploying. We recommend
+ doing this all from your Baserock development machine, using a Baserock
+ ARM distributed build network to produce the system artifact. Once both
+ system artifacts are cached locally, the `morph deploy` command will produce
+ a self-extracting shell script/tarball following the 'location' field.
+
+ See the documentation of the sdk.write extension for more information.
+systems:
+- morph: systems/armv7lhf-cross-toolchain-system.{{CONFIG}}.morph
+ deploy:
+ sdk:
+ type: extensions/sdk
+ location: armv7lhf-cross-toolchain-system.sh
+ PREFIX: /usr
+ TARGET: armv7lhf-baserock-linux-gnueabi
+ subsystems:
+ - morph: systems/devel-system.armv7lhf.morph
+ deploy:
+ sysroot:
+ type: extensions/sysroot
+ location: usr/armv7lhf-baserock-linux-gnueabi/sys-root