| Age | Commit message (Collapse) | Author |
|---|
|
All build artifacts should be deployed in a single `*.tar.zst` file.
This archive and the single top-level content (a directory called `*` in
this case) should contain the project name and version in its name.
The latter is added with this commit so that there is now an
`iot-contact-v0.0.0-dev.tar.zst` instead of an `iot-contact.tar.zst`.
|
|
This commit removes the path transformations apart from
project-prefixing from the deploy tree / artifact file archive.
This gives the source tree, build tree and deploy tree the same
directory hierarchy.
The advantages are simple implementation and maintenance and a common
structure for all parties (users, developers, producers, ...).
The disadvantage is obviously that the deploy tree structure cannot be
customized on its own. At least for now the approach "there is one right
structure to rule them all" is taken.
|
|
|
|
This generates `build/iot-contact.tar.zst` as primary build artifact. It
contains all artifacts which should be deployed. Providing this as file
archive makes further handling more easy.
|
|
This was just a trick to provide a folder in the build tree where only
artifacts are stored. These artifacts are moved to the root of the build
tree.
This has the disadvantage that they are mixed with other files inside
this folder. Nevertheless they should soon be added by Meson to the file
archive used for deployment which solves this issue because it contains
by definition only artifacts.
|
|
Using the installation step to copy selected artifacts into one folder
was anyway a hack.
This commit shows that the complexity can be reduced by adding copy
targets. The `build/artifacts` folder contains the selected artifacts,
they are always up to date, the user does not have to call the install
step separately and the target definitions do not require
install-related keyword arguments.
|
|
|
|
A static site generator is currently not really required. A static
index.html is currently sufficient.
|
|
|
|
This allows to re-use these scripts. Since they are currently used to
build Zephyr builds and three are intended (application, bootloader and
application as native_sim build) this makes sense.
|
|
CMake ExternalProject creates a pretty confusing build tree. Since the
rest of the project anyway starts moving to Meson the bootloader is
configured via Meson as a first step.
|
|
This makes the build system code way less hacky and more modular.
|
|
This allows to install the PCB-related files easier to the website which
is built with Meson.
|
|
This uses meson to copy the simple.css file to the build dir and
references the CSS file in the HTML code.
|
|
CMake has some disadvantages when building subprojects like with
`ExternalProject`. Furthermore the language is sometimes hard to read,
hard to write and not so much appreciated.
This is a little test if meson might perform better. If successful this
project might switch to meson for all parts except the Zephyr builds.
|
