|
2 | 2 |
|
3 | 3 | Recipes for MeVisLab Thirdparty packages |
4 | 4 |
|
5 | | -The `recipes` directory contains all recipes. The overall build order is currently defined in the `build_configuratuion.yml`. |
| 5 | +The `recipes` directory contains all recipes. The overall build order is currently defined in the `build_configuration.yml`. |
6 | 6 |
|
7 | 7 | ## Local package development |
8 | 8 |
|
9 | 9 | ### Preconditions |
10 | 10 |
|
11 | | -First of all we need [Python >=3.9 and Pip](https://www.python.org/). |
| 11 | +First of all we need [Python >=3.10 and Pip](https://www.python.org/). |
| 12 | +Currently we recommend Python 3.11. |
12 | 13 |
|
| 14 | +Check the installed versions with: |
13 | 15 | ``` |
14 | 16 | python -V |
15 | 17 | pip --version |
16 | 18 | ``` |
17 | 19 |
|
18 | | -Note that on all platforms except Windows the Python 3 executables are mostly called `python3` while `pip3`/`pip` don't exist at all. But to be compatible with Windows _(yes, that's the wrong way around - blame MS!)_, we currently need the `python` and `pip` symlinks point to `python3` and `pip3` _(or better `python3 -m pip`)_ respectively. Everything else may work, but has not been tested. |
| 20 | +Note that on POSIX platforms the Python 3 executable is called `python3`, while under Windows it is called `python`. |
| 21 | +Additionally, under POSIX, `pip3` is not installed per default, while under Windows it is installed with Python as `pip`. |
| 22 | +To be compatible with Windows _(yes, that's the wrong way around - blame MS!)_, we currently need the `python` and `pip` symlinks point to `python3` and `pip3` _(or better `python3 -m pip`)_ respectively. Everything else may work, but has not been tested. |
19 | 23 |
|
20 | 24 | Note also that on current Windows versions [Microsoft hijacks](https://docs.microsoft.com/en-us/windows/python/faqs#why-does-running-pythonexe-open-the-microsoft-store) the `python` and `python3` executables. |
21 | 25 |
|
22 | 26 |
|
23 | 27 | ### Install Conan |
24 | 28 |
|
25 | 29 | [Conan](https://conan.io) is the package manager used to build our third party libraries. |
26 | | -Additionally, we are using [Conan Package Tools](https://github.com/conan-io/conan-package-tools) to generate multiple binary packages from a recipe with ease. |
27 | | - |
28 | | -Both packages can be installed using pip: |
| 30 | +On Windows, use: |
29 | 31 | ``` |
30 | | -python -m pip install -U conan conan-package-tools |
| 32 | +python -m pip install -U conan packaging spdx-license-list tomli |
31 | 33 | ``` |
32 | 34 |
|
33 | | -Now conan should be installed: |
| 35 | +On Linux, use: |
34 | 36 | ``` |
35 | | -conan --version |
| 37 | +pip3 install -U conan packaging spdx-license-list tomli pyelftools |
36 | 38 | ``` |
37 | 39 |
|
38 | | -### Install MeVisLab Build Tool |
39 | | - |
40 | | -`mbt`, the MeVisLab Build Tool, is a small wrapper for Conan and the Conan Package Tools. |
41 | | -It mainly ensures that Conan is properly configured and initialized before invoking conan itself. |
42 | | - |
43 | | -``` |
44 | | -python -m pip install -U git+http://gitlab.mevis.lokal/mevislab/mbt.git |
45 | | -``` |
46 | 40 |
|
47 | 41 | ## Build a package |
48 | 42 |
|
49 | | -### Using mbt, conan-package-tools or conan |
50 | | - |
51 | | -All wrappers (`mbt`, `conan-package-tools`) are just convenience. |
52 | | -They make certain things easier, while making advanced things very difficult. |
53 | | -That seems to be the nature of wrappers. Therefore it is always possible to |
54 | | -work without these tools. |
55 | | - |
56 | | -So a recipe can be built directly with `mbt`: |
57 | | - |
| 43 | +To build the debug and release versions of a package: |
58 | 44 | ``` |
59 | 45 | cd recipes/<recipe_name> |
60 | | -mbt build |
61 | | -``` |
62 | | - |
63 | | -_Note_: If you are building under Windows, have several Visual Studio versions installed and want to use _not_ the |
64 | | -newest one, you have to set an environment variable with the desired version to communicate this to `mbt`: |
65 | | -``` |
66 | | -SET CONAN_VISUAL_VERSIONS=16 |
| 46 | +conan create -s build_type=Debug . |
| 47 | +conan create -s build_type=Release . |
67 | 48 | ``` |
68 | 49 |
|
69 | | -Or using `conan-package-tools`: |
| 50 | +If you have the `conan-config` package installed (MeVisLab internal only, see README.md in the main MeVisLab directory), you can instead use: |
70 | 51 | ``` |
71 | 52 | cd recipes/<recipe_name> |
72 | | -./build.py |
| 53 | +conan tp:build . |
73 | 54 | ``` |
| 55 | +to build both the debug and release packages. |
| 56 | + |
74 | 57 |
|
75 | | -Or using `conan`: |
| 58 | +To fetch the package sources (includes applying patches): |
76 | 59 | ``` |
77 | 60 | cd recipes/<recipe_name> |
78 | | -conan create . |
| 61 | +conan source . |
79 | 62 | ``` |
80 | 63 |
|
| 64 | + |
81 | 65 | ## Jenkins Integration |
82 | 66 |
|
83 | 67 | ### Pipeline Description |
84 | | -There are mainly two Jenkinsfiles that control the build of all thirdparty library and tools: Jenkinsfile and JenkinsfileLibrary. The first parses the `build_configuration.yml` and triggers the build of one tier after the other, starting with tier0. For further details see the chapter Build Configuration |
| 68 | +There are mainly two Jenkins files that control the build of all thirdparty libraries and tools: `Jenkinsfile` and `JenkinsfileLibrary` (both in the repository root). The first file parses `build_configuration.yml` and triggers the sequential build of all tiers, starting with tier0. For further details see the chapter _Build Configuration_. |
85 | 69 |
|
86 | | -The conan package system is written in a way that it checks if the package itself or one of its dependencies has been changed since the last successful build. If nothing has changed then the build and archiving step is been skipped. |
87 | | -Since even this check takes a certain amount of time, an additional optimization has been implemented. All changed files are collected since the last successful build of the complete thirdparty/branch build. And only those directly affected projects and the tiers below are triggered to be rebuild. This shortens the build time enormously. If one of the files `Jenkinsfile`, `JenkinsfileLibrary`, or `build_configuration.yml` is part of any changeset, then this optimisation is skipped and all tiers with all projects are build. |
| 70 | +The conan package system is written in a way that it checks if the package itself or one of its dependencies has been changed since the last successful build. If nothing has changed, then the build and archiving step is skipped. |
| 71 | +Since even this check takes a certain amount of time, an additional optimization has been implemented. All changed files are collected since the last successful build of the complete thirdparty/branch build. And only those directly affected projects and the tiers below are triggered to be rebuild. This shortens the build time enormously. If one of the files `Jenkinsfile`, `JenkinsfileLibrary`, or `build_configuration.yml` is part of any changeset, then this optimization is skipped and all tiers with all projects are build. |
88 | 72 |
|
89 | 73 | ### Build Configuration |
90 | | -The build configuration is organised in the `build_configuration.yml` file. All libraries and tools that are needed to build MeVisLab are organised in this file. Since it very tedios and cumpersome to descripe smallest possible dependecy graph, the dependencies are broken down in different tiers. The content of the different tier is organised according to the dependencies of the individual libraries and tools. So if a e.g. a library A depends on an other library B, then B must be referenced in an one of the upper tiers. |
| 74 | +The build configuration is described in the `build_configuration.yml` file, which references all the libraries and tools needed to build MeVisLab. |
| 75 | +Organizing the dependencies can be very tedious and cumbersome, especially when attempting to describe the smallest possible dependency graph. |
| 76 | +To simplify this, dependencies are broken down into different tiers, with the content of each tier organized according to the dependencies of the individual libraries and tools. |
| 77 | +For instance, if library A depends on another library B, then B must be referenced in one of the upper tiers (e.g. a tier with a lower number). |
91 | 78 |
|
92 | | -The build of each library and tool for all specified platform and build types must finish in a defined time. There is a default, that is been used for all packages. In case that a certain package needs much more time, e.g. qt5, then there is the possibility to define a timeout exception. |
| 79 | +The build of each library and tool for all specified platforms and build types must finish within a defined time frame. There is a default timeout that is used for all packages. |
| 80 | +However, if a certain package requires significantly more time, there is the possibility to define a timeout exception. |
93 | 81 |
|
94 | 82 | These are the parameters that are defined in the file: |
95 | 83 |
|
96 | 84 | | Parameter | Description | |
97 | 85 | | --------- | ------------| |
98 | | -| timeout_default: | Default time in minutes for all not other specified packages. | |
99 | | -| timeout_exception: | A map of all packages with their individual timeouts. | |
100 | | -| tiers: | It must contain an ordered list of all tiers, starting with tier0 | |
| 86 | +| timeout_default: | Default time in minutes for all packages not specified otherwise | |
| 87 | +| timeout_exception: | A map of all packages with their individual timeouts | |
| 88 | +| tiers: | An ordered list of all tiers, starting with tier0 | |
0 commit comments