On Aug 17, 2007, at 9:51 PM, Olivier Thauvin wrote:
After a short discussion on irc with Jeff, I decide to work on the
part I know
the best: build/.
My goal is to provide a way to cleanly build a packages (so many
packages) for
many architectures (--target foo --target bar) in envirronement and
w/o the
current recursivity.
OK. So you want a "build system" tool able to build package(s) for
multiple target platforms.
You need to look at the fundamental design issue first:
Multiple target platforms (in general) is more than i[3456]86
targets,
and that means remote execution (or emulation).
You also should think through what a "build environment" means. ATM,
rpmbuild's connection to managing the "environment" is nothing more than
setting up per-target macros, verifying build dependencies, and reaping
scriptlet(s) status for a single build.
Very specifically _NOT_ attempted are the mechanics of entering/
leaving a chroot,
installing missing build elements, remote scriptlet execution,
logging output, etc.
My though is to create a struct to hold all info related to build:
struct Spec_s {
const char specfile;
[...]
}
struct buildenv_s {
Spec spec;
scripts ...
Packages ...
}
These are the wrong abstraction(s).
For starters, "package" is way too imprecise a concept to
define object methods.
Now the problem... In an ideal world, rpm -ba pkg.spec --target foo
--target
bar should build one src.rpm and for each platform one or more binary.
Currently a src.rpm is build for each platform, normally overriding
each one
overriding the previous.
But in real world, nothing can prevent this kind of spec (worst case):
Name: foo-%{_target_arch}
Source: foo-%{_target_arch}.tar.gz
Buildrequires: bar-%{_target_arch}
Reviewing:
Name: this will works, creating foo-i586.src.rpm, foo-ppc.src.rpm,
etc...
Source: this will probably cause issue, as only one source will packed
Buildrequires: this will works and is probably use, this end as
Requires in
the src.rpm.
The spec should be expand for each architecture, so in case I
rework the build
part,, I am thinking to first parse the spec (preamble only) to
generate
src.rpm with a fake platform to really deny spec like I exposed
previously.
There already is a loop over multiple target platforms in build.c,
and the
entire configuration is trashed and reloaded for each loop traversal.
Far more reliable is the simple shell loop
for t in target1 target2 target3; do rpmbuild -ba --target $t
foo.spec; done
OTOH, I do believe that generating a *.src.rpm immediately after
parsing,
not after building (as currently), starts to address the fundamental
issue of
multiple srpm's, with possibly differing content, being generated on
multiple
target(s).
The fundamenatl design decision will be whether there is one single
canonical
master src.rpm, or whether srpm's indeed should be considered per-
platform
with potentially different content.
I'm much less enthusiastic about "fake platform" ...
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
