[buckminster-dev] Re: mspec problems with released buckminster

[Carsten Reckord <creckord@xxxxxxxxxxxxx>]

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)

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.
Index: buckminster/src/main/java/hudson/plugins/buckminster/EclipseBuckminsterBuilder.java
===================================================================
--- buckminster/src/main/java/hudson/plugins/buckminster/EclipseBuckminsterBuilder.java (revision 19726)
+++ buckminster/src/main/java/hudson/plugins/buckminster/EclipseBuckminsterBuilder.java (working copy)
@@ -7,6 +7,7 @@
 import hudson.model.BuildListener;
 import hudson.model.Descriptor;
 import hudson.model.FreeStyleProject;
+import hudson.matrix.MatrixProject;
 import hudson.tasks.BuildStepDescriptor;
 import hudson.tasks.Builder;
 import hudson.util.FormValidation;
@@ -203,19 +204,24 @@
                        writer = new PrintWriter(new FileWriter(commandsPath));
 
                        String[] commands = getCommands().split("[\n\r]+");
-                       for (int i = 0; i < commands.length; i++) {
+                        
+                        Map<String, String> properties = build.getEnvironment(listener);
+                        Map<String, String> buildVars = build.getBuildVariables();
+                        properties.putAll(buildVars);
+
+                        for (int i = 0; i < commands.length; i++) {
                                if (!commands[i].startsWith("perform") || commands[i].startsWith("perform -D buckminster.output.root="))
                                        // the command is not perform -> nothing to modify
                                        //or
                                        //the command is a perform, but with explicit output root
-                                       writer.println(expandProperties(commands[i],build.getEnvironment(listener)));
+                                       writer.println(expandProperties(commands[i], properties));
                                else {
                                        // perform will usually produce build artifacts
                                        // set the buckminster.output.root to the job's workspace
                                        writer.print("perform -D buckminster.output.root=\""
                                                        + build.getProject().getWorkspace().toURI().getPath()+"/buckminster.output\"");
                                        String commandAfterPerform = commands[i].replaceFirst("perform", "");
-                                       commandAfterPerform = expandProperties(commandAfterPerform, build.getEnvironment(listener));
+                                       commandAfterPerform = expandProperties(commandAfterPerform, properties);
                                        writer.println(commandAfterPerform);
                                        // TODO: let the user set more properties
 
@@ -375,7 +381,7 @@
 
                @Override
                public boolean isApplicable(Class<? extends AbstractProject> jobType) {
-                       return FreeStyleProject.class.isAssignableFrom(jobType);
+                       return FreeStyleProject.class.isAssignableFrom(jobType) || MatrixProject.class.isAssignableFrom(jobType);
                }
        }
 }