1 |
Hello, |
2 |
|
3 |
Recently python-r1 and multilib-build started to share a few bits |
4 |
of code related to running the build process for multiple 'variants' |
5 |
of the same package. Over time, the code extended and it is a bit |
6 |
cumbersome to maintain the two copies and keep them in sync. |
7 |
|
8 |
Therefore, I'd like to propose a new multibuild.eclass which will |
9 |
provide a generic framework for eclasses and ebuilds to perform |
10 |
multi-variant builds. |
11 |
|
12 |
|
13 |
The eclass currently is intended to provide two functions: |
14 |
- multibuild_foreach, |
15 |
- multibuild_parallel_foreach. |
16 |
|
17 |
These functions are supposed to execute the child process for each |
18 |
of the enabled variants with support for the following: |
19 |
|
20 |
- setting BUILD_DIR to an unique location which can be used to build |
21 |
the sources, |
22 |
|
23 |
- teeing logs to a variant-specific log file to make reading them |
24 |
easier, |
25 |
|
26 |
- nesting multiple uses of multibuild.eclass -- e.g. fftw build 3-4 |
27 |
'float type' variants + multilib. |
28 |
|
29 |
It also fixes some of the issues that were noticed within |
30 |
distutils-r1 / python-r1. |
31 |
|
32 |
|
33 |
I will send patches in the reply to this message. The patches: |
34 |
|
35 |
1) introduce the initial version of multibuild based on the code |
36 |
from python-r1 and distutils-r1, |
37 |
|
38 |
2) improve running 'tee' to a method not requiring subshelling |
39 |
the called function, |
40 |
|
41 |
3) fix an issue of trying to write ${WORKDIR%/}-${impl} if S=${WORKDIR}, |
42 |
|
43 |
4) convert multilib-build to use the new eclass, |
44 |
|
45 |
5) provide python-r1 with a function to obtain enabled implementation |
46 |
list to make the migration possible, |
47 |
|
48 |
6) convert python-r1 and distutils-r1 to use the new eclass, |
49 |
|
50 |
7) move run_in_build_dir() common function to the new eclass, |
51 |
|
52 |
8) convert sci-libs/fftw to the new eclass as an example of nested use. |
53 |
|
54 |
|
55 |
That's just the initial approach. If it works fine, the todo lists: |
56 |
|
57 |
1) supporting nested parallel builds, |
58 |
|
59 |
2) adding a function to run a snippet with just one ('default') variant, |
60 |
|
61 |
and possibly more. |
62 |
|
63 |
|
64 |
What are your thoughts? |
65 |
|
66 |
-- |
67 |
Best regards, |
68 |
Michał Górny |