public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* [gentoo-dev] [RFC] multibuild.eclass -- a generic pluggable framework to handle multi-variant builds
@ 2013-02-27 21:41 99% Michał Górny
  0 siblings, 0 replies; 1+ results
From: Michał Górny @ 2013-02-27 21:41 UTC (permalink / raw
  To: gentoo-dev; +Cc: python

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-02-27 21:41 99% [gentoo-dev] [RFC] multibuild.eclass -- a generic pluggable framework to handle multi-variant builds Michał Górny

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox