custom build environments?

[Les Mikesell]

Does anyone have suggestions for how to get Jenkins to make Linux
builds that don't match the stock system environment that
autoconf/configure would find?  For example, if you want to have
multiple versions of boost installed and compile jobs that each need
some specific version.

--
   Les Mikesell
     [hidden email]

[Mark Waite]

I experimented once with a "chroot" environment as a way to have different configurations on the same Linux machine.  I found chroot to be more complicated than I was ready to use at the time, but I believe it can be used to provide different executable versions hosted over the same Linux kernel.

 

If you need different Linux kernels in addition to different libraries and tools, then I think you'll need separate machines (physical or virtual).

 

Mark Waite

From: Les Mikesell <[hidden email]>
To: jenkinsci-users <[hidden email]>
Sent: Wednesday, February 22, 2012 1:19 PM
Subject: custom build environments?

Does anyone have suggestions for how to get Jenkins to make Linux
builds that don't match the stock system environment that
autoconf/configure would find?  For example, if you want to have
multiple versions of boost installed and compile jobs that each need
some specific version.

--
  Les Mikesell
    [hidden email]

[Dean Yu]

We have an internal plugin that manages chroots for exactly this scenario. We set up the chroot through a BuildWrapper, and we override the launch method so that each build step enters the chroot before it executes. There’s a lot of internal-only code in here, so it’s not something we can open source. However, if you want more information, I can sketch out some more detail for you.

  -- Dean


On 2/22/12 2:57 PM , "Mark Waite" <markwaite@...> wrote:

I experimented once with a "chroot" environment as a way to have different configurations on the same Linux machine.  I found chroot to be more complicated than I was ready to use at the time, but I believe it can be used to provide different executable versions hosted over the same Linux kernel.
 
If you need different Linux kernels in addition to different libraries and tools, then I think you'll need separate machines (physical or virtual).
 
Mark Waite

 
 

 
 From: Les Mikesell <lesmikesell@...>
 To: jenkinsci-users <jenkinsci-users@...>
 Sent: Wednesday, February 22, 2012 1:19 PM
 Subject: custom build environments?
 
 
Does anyone have suggestions for how to get Jenkins to make Linux
builds that don't match the stock system environment that
autoconf/configure would find?  For example, if you want to have
multiple versions of boost installed and compile jobs that each need
some specific version.

[Nord, James]

What we have done is use maven to setup the environment with some calls to tar etc.

We build boost and store it (versioned) in a maven repo (as tar.gz including object headers etc).

Then what needs boost downloades it and unpacks it into a workspace relative path.The make scrips are all configured to use workspace relative paths so to get a different version you change the maven dependency.

 

Its relatively simple – just make sure you use the platform tar not maven assembly plugin to create the archive (or you loose the symlinks).

 

As you’re using autoconf I would guess you then need to pass in –with-boost=./boost or something equivellent

 

Hope that helps (although the chroot sounds much better J )

 

                /james

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dean Yu
Sent: 23 February 2012 01:05
To: [hidden email]; Mark Waite
Subject: Re: custom build environments?

 

We have an internal plugin that manages chroots for exactly this scenario. We set up the chroot through a BuildWrapper, and we override the launch method so that each build step enters the chroot before it executes. There’s a lot of internal-only code in here, so it’s not something we can open source. However, if you want more information, I can sketch out some more detail for you.

  -- Dean


On 2/22/12 2:57 PM , "Mark Waite" <markwaite@...> wrote:

I experimented once with a "chroot" environment as a way to have different configurations on the same Linux machine.  I found chroot to be more complicated than I was ready to use at the time, but I believe it can be used to provide different executable versions hosted over the same Linux kernel.
 
If you need different Linux kernels in addition to different libraries and tools, then I think you'll need separate machines (physical or virtual).
 
Mark Waite

 
 

 
 From: Les Mikesell <lesmikesell@...>
 To: jenkinsci-users <jenkinsci-users@...>
 Sent: Wednesday, February 22, 2012 1:19 PM
 Subject: custom build environments?
 
 
Does anyone have suggestions for how to get Jenkins to make Linux
builds that don't match the stock system environment that
autoconf/configure would find?  For example, if you want to have
multiple versions of boost installed and compile jobs that each need
some specific version.

---

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Mandeville, Rob]

Another possibility would be to put Boost in a non-standard location where autoconf/configure would never find it, install various versions of Boost that you need into various directories, and then pass command-line arguments to autoconf/configure specifying where to get your Boost library from.

 

A third one would be not to install Boost on your build host at all, but to throw the various versions into source control (or artifact repository) and pull them out at compile time as needed.

 

--Rob Mandeville

Litle & Co.

www.litle.com

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dean Yu
Sent: Wednesday, February 22, 2012 8:05 PM
To: [hidden email]; Mark Waite
Subject: Re: custom build environments?

 

We have an internal plugin that manages chroots for exactly this scenario. We set up the chroot through a BuildWrapper, and we override the launch method so that each build step enters the chroot before it executes. There’s a lot of internal-only code in here, so it’s not something we can open source. However, if you want more information, I can sketch out some more detail for you.

  -- Dean


On 2/22/12 2:57 PM , "Mark Waite" <markwaite@...> wrote:

I experimented once with a "chroot" environment as a way to have different configurations on the same Linux machine.  I found chroot to be more complicated than I was ready to use at the time, but I believe it can be used to provide different executable versions hosted over the same Linux kernel.
 
If you need different Linux kernels in addition to different libraries and tools, then I think you'll need separate machines (physical or virtual).
 
Mark Waite

 
 

 
 From: Les Mikesell <lesmikesell@...>
 To: jenkinsci-users <jenkinsci-users@...>
 Sent: Wednesday, February 22, 2012 1:19 PM
 Subject: custom build environments?
 
 
Does anyone have suggestions for how to get Jenkins to make Linux
builds that don't match the stock system environment that
autoconf/configure would find?  For example, if you want to have
multiple versions of boost installed and compile jobs that each need
some specific version.

The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.

[Les Mikesell]

On Thu, Feb 23, 2012 at 6:42 AM, Mandeville, Rob <[hidden email]> wrote:
> Another possibility would be to put Boost in a non-standard location where
> autoconf/configure would never find it, install various versions of Boost
> that you need into various directories, and then pass command-line arguments
> to autoconf/configure specifying where to get your Boost library from.

We do this on windows where there is no "standard location" for boost.
 We have a common mapped drive with several versions and the
developers can set a variable for which one they want.   But now I'd
like to make a matrix build work across several versions of windows
and linux targets where one of the linux targets will have the
expected boost version installed natively but others will not. So
there are really two parts to the issue:  first is it sane to even
build something against the wrong libs on linux, and second, how do
you map something in a matrix job to things that are location-specific
per node?

--
   Les Mikesell
    [hidden email]

[Ringo De Smet]

Hello Dean,

On 23 February 2012 02:04, Dean Yu <[hidden email]> wrote:

We have an internal plugin that manages chroots for exactly this scenario. We set up the chroot through a BuildWrapper, and we override the launch method so that each build step enters the chroot before it executes. There’s a lot of internal-only code in here, so it’s not something we can open source. However, if you want more information, I can sketch out some more detail for you.

Would you be able to OpenSource your internal plugin after stripping out the internal-only code?

Ringo