Mailing-List: contact builds-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: builds@apache.org
MIME-Version: 1.0
Sender: shaposhnik@gmail.com
In-Reply-To: <45a7a79f-1c39-8ebf-5266-2a474d3721ee@schor.com>
References: <45a7a79f-1c39-8ebf-5266-2a474d3721ee@schor.com>
From: Roman Shaposhnik <roman@shaposhnik.org>
Date: Tue, 17 Jan 2017 09:43:11 -0800
Message-ID: <CA+ULb+ts-6MGfCGLS6Gf1-JkAoU+j=80Y+M6-O4bbh9Et03pmA@mail.gmail.com>
Subject: Re: Jenkins support for C++ builds, standard dependent components?
To: "builds@apache.org" <builds@apache.org>
Cc: uima-dev <dev@uima.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 17 Jan 2017 17:43:17 -0000

On Tue, Jan 17, 2017 at 9:39 AM, Marshall Schor <msa@schor.com> wrote:
> Hi,
>
> We have part of our project that is in C++.  We're looking into a Jenkins job
> for CI for it.
>
> It requires as prerequisites: Apache APR, ICU, Xerces, and maybe some other
> somewhat standard components.
>
> When building on private machines, the technique is to obtain these by either
> installing prebuilt versions, or first "building" these, more or less as a one
> time operation (repeated sometimes when toolchain levels change).
>
> What's the best practice on Apache Jenkins?  Are there a group of machines where
> somewhat standard packages like the above are installed (at various versions)?
> If so, is there a standard naming of these to find them?  If not, should each
> build do its own build of these components, every time the build runs?

Personally, I've recommended and used Docker containers as a way to capture
the build environment to a great deal of success. The bonus points is that it
also gives a 100% reproducible build environment to your community. Which means
no longer having "but it builds on my machine!" arguments.

Thanks,
Roman.