From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: python@gentoo.org
Subject: [gentoo-dev] [RFC] multibuild.eclass -- a generic pluggable framework to handle multi-variant builds
Date: Wed, 27 Feb 2013 22:41:52 +0100 [thread overview]
Message-ID: <20130227224152.6d1293c9@pomiocik.lan> (raw)
[-- 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 --]
next reply other threads:[~2013-02-27 21:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 21:41 Michał Górny [this message]
2013-02-27 21:43 ` [gentoo-dev] [PATCH 1/8] Initial version of multibuild eclass Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 2/8] Use bash redirection to run 'tee' rather than simple pipes Michał Górny
2013-02-28 13:09 ` Alec Warner
2013-02-28 14:53 ` Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 3/8] Avoid writing outside WORKDIR if S=${WORKDIR} Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 4/8] Convert multilib-build to use multibuild Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 5/8] python-r1: calculate final list of enabled impls for foreach Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 6/8] Convert python-r1 to use multibuild Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 7/8] Move run_in_build_dir() to multibuild.eclass Michał Górny
2013-02-27 21:43 ` [gentoo-dev] [PATCH 8/8] fftw: example use of multibuild in ebuild Michał Górny
2013-03-02 23:19 ` Christoph Junghans
2013-03-02 21:42 ` [gentoo-dev] Further changes to multibuild.eclass Michał Górny
2013-03-02 21:42 ` [gentoo-dev] [PATCH 1/4] multibuild: print only 'public' part of command-line Michał Górny
2013-03-02 22:52 ` Alec Warner
2013-03-02 23:03 ` Michał Górny
2013-03-02 21:42 ` [gentoo-dev] [PATCH 2/4] multibuild: add multibuild_for_best_variant() Michał Górny
2013-03-02 21:42 ` [gentoo-dev] [PATCH 3/4] multilib-build: introduce multilib_for_best_abi() Michał Górny
2013-03-02 21:42 ` [gentoo-dev] [PATCH 4/4] distutils-r1: reuse multibuild_for_best_variant Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130227224152.6d1293c9@pomiocik.lan \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=python@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox