You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2014/03/13 13:34:51 UTC

Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn

On 13.03.2014 12:42, stsp@apache.org wrote:
> Author: stsp
> Date: Thu Mar 13 11:42:08 2014
> New Revision: 1577117
>
> URL: http://svn.apache.org/r1577117
> Log:
> * tools/dev/unix-build/Makefile.svn: Add gettext support to my custom
>    build script, which is also used on the bb-openbsd bot. My own svn
>    development builds now support i18n so I can test related code paths.

I'm frankly not thrilled by the existence of "your own build script."
How on earth do we know that what works for you will work for the rest
of us who use the standard "autogen.sh; configure; make" sequence?

(FWIW, the fact that the bb-openbsd bot uses a different script from
other bots is also a problem, but IIUC Ben is working on addressing that.)

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn

Posted by Ben Reser <be...@reser.org>.
On 3/13/14, 6:40 AM, Stefan Sperling wrote:
>> (FWIW, the fact that the bb-openbsd bot uses a different script from
>> other bots is also a problem, but IIUC Ben is working on addressing that.)
> 
> I'm quite happy that I have reproducible builds on OpenBSD and if necessary
> other *nix-like systems with full control and automation.
> 
> If Ben invents something similar that's great.
> I believe that diversity in the buildfarm doesn't hurt.

Branko's referring to my project to try and cleanup up the buildbot builders to
get them have some consistency.  By that I mean the following:

* Similar build bot setup patterns, I'd like to see the setup in the master
config be nearly identical for all the builders.  This doesn't mean all the
bots need to do the same tests or use the same dependencies.  Each builder is
still going to have all of their own scripts.

* Have all the builders get their scripts from Subversion
(trunk/tools/buildbot/slaves) in an automated way, allowing any of us to
disable tests or tweak the testing.

I completely agree that the build should be repeatable, we could get some of
that by using separate installs of the dependencies just for the bot, but I
think we want to test OS provided dependencies as well.  So at least some of
the bots, reproducibility comes down to someone not screwing with the installed
dependencies.

Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn

Posted by Stefan Sperling <st...@elego.de>.
On Thu, Mar 13, 2014 at 01:34:51PM +0100, Branko Čibej wrote:
> On 13.03.2014 12:42, stsp@apache.org wrote:
> > Author: stsp
> > Date: Thu Mar 13 11:42:08 2014
> > New Revision: 1577117
> >
> > URL: http://svn.apache.org/r1577117
> > Log:
> > * tools/dev/unix-build/Makefile.svn: Add gettext support to my custom
> >    build script, which is also used on the bb-openbsd bot. My own svn
> >    development builds now support i18n so I can test related code paths.
> 
> I'm frankly not thrilled by the existence of "your own build script."
> How on earth do we know that what works for you will work for the rest
> of us who use the standard "autogen.sh; configure; make" sequence?

I want to control the set of dependencies independently from
what the operating system provides.

I want gdb traces into dependencies with debug symbols.

I want to type 'make', not all the crazy commands that the Makefile automates.

I was maintaining this Makefile outside of our repository for a long time.
Some years ago Hyrum suggested that I move it into our repo in case
it is useful to someone. If you're not happy with that I can move it elsewhere.

> (FWIW, the fact that the bb-openbsd bot uses a different script from
> other bots is also a problem, but IIUC Ben is working on addressing that.)

I'm quite happy that I have reproducible builds on OpenBSD and if necessary
other *nix-like systems with full control and automation.

If Ben invents something similar that's great.
I believe that diversity in the buildfarm doesn't hurt.