[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: mspec problems with released buckminster
|
Hi Carsten, see comments inline.
Carsten Reckord schrieb:
Hi Johannes,
On 15.07.2009 15:11, Johannes Utzig wrote:
Hi Carsten,
thank you for your reply, looks like we have a habit of running into
the same bugs :)
Looks like it :)
An unrelated question: Currently the Hudson Buckminster builder does
not show up in multi-configuration projects. Is this just a
configuration issue or are there additional requirements for a
builder to support that?
Well, this is quite easy to explain. In a builder you let hudson know
what kinds of jobs you are supporting and the builder will only be
visible in these projects. Since I only ever used the freestyle
project so far I did not add any support for other job types.
If that is an requirement of yours that can be arranged. Would you
please let me know more about your use-case and what you'd expect to
plugin to do?
Once I know the requirement better, I am quite positive that you can
have the support for matrix job types relativly soon.
From what I remember of reading about the matrix job, the builder
will be called several times with a new set of special
matrix-properties each time. Supporting that doesn't sound too
difficult...
My use case is products for different platforms. We'd like to build
products containing the platform-specific libraries and executable for a
set of platforms without including all the libraries for the other
platforms, too. If I understood the matrix jobs correctly, the axes are
available as variables for the build steps and the job makes sure that
the build is run for all valid combinations of axes. So basically we'd
like to do something like
axis os = win32 linux macosx
axis ws = win32 gtk cocoa carbon
axis arch = x86 x86_64
(bunch of combination filters)
I thought buckminster itself provider the means of building platform
agnostic
target.os=${*} ...
I must admit that it never quite worked for me but I think there's
something like that already implemented.
Apart from that, this requirement totally makes sense of course.
bucky build step
resolve -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch}
our.mspec
perform -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch}
our.product.feature#create.product
Currently, we are using multiple projects for (a subset of) this, which
is okay once it's set up, but it's gonna be a maintenance nightmare come
some changes to the build...
I've enabled the Buckminster builder for matrix projects in my local
version and played around with it a bit. To get things running, the
EclipseBuckminsterBuilder needs to also use the variables from
getBuildVars() for expansion. I've simply merged the two maps into one,
don't know if that's the right way to apply them, but it works nicely
for me. I've attached a patch with my changes.
Thank you very much for the patch, that's what I thought needs to be
done. I'll have a look into it, do some tests with matrix builds on my
own and bump up a new version today or tomorrow if everything works fine.
Please let me know when there are other things that you'd like to see in
the plugin.
Best regards,
Johannes