[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] [RFC] multibuild.eclass -- a generic pluggable framework to handle multi-variant builds
From:       Michał Górny <mgorny () gentoo ! org>
Date:       2013-02-27 21:41:52
Message-ID: 20130227224152.6d1293c9 () pomiocik ! lan
[Download RAW message or body]


Hello,

Recently python-r1 and multilib-build started to share a few bits
of code related to running the build process for multiple 'variants'
of the same package. Over time, the code extended and it is a bit
cumbersome to maintain the two copies and keep them in sync.

Therefore, I'd like to propose a new multibuild.eclass which will
provide a generic framework for eclasses and ebuilds to perform
multi-variant builds.


The eclass currently is intended to provide two functions:
- multibuild_foreach,
- multibuild_parallel_foreach.

These functions are supposed to execute the child process for each
of the enabled variants with support for the following:

- setting BUILD_DIR to an unique location which can be used to build
  the sources,

- teeing logs to a variant-specific log file to make reading them
  easier,

- nesting multiple uses of multibuild.eclass -- e.g. fftw build 3-4
  'float type' variants + multilib.

It also fixes some of the issues that were noticed within
distutils-r1 / python-r1.


I will send patches in the reply to this message. The patches:

1) introduce the initial version of multibuild based on the code
from python-r1 and distutils-r1,

2) improve running 'tee' to a method not requiring subshelling
the called function,

3) fix an issue of trying to write ${WORKDIR%/}-${impl} if S=${WORKDIR},

4) convert multilib-build to use the new eclass,

5) provide python-r1 with a function to obtain enabled implementation
list to make the migration possible,

6) convert python-r1 and distutils-r1 to use the new eclass,

7) move run_in_build_dir() common function to the new eclass,

8) convert sci-libs/fftw to the new eclass as an example of nested use.


That's just the initial approach. If it works fine, the todo lists:

1) supporting nested parallel builds,

2) adding a function to run a snippet with just one ('default') variant,

and possibly more.


What are your thoughts?

-- 
Best regards,
Michał Górny

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]