We need binary builds for Windows and Mac (and everything else)

Matt Mackall mpm at selenic.com
Thu Feb 26 02:45:31 CST 2009


On Thu, 2009-02-26 at 09:17 +0100, Stefan Rusek wrote:
> On Thu, Feb 26, 2009 at 9:02 AM, Matt Mackall <mpm at selenic.com> wrote:
> > On Thu, 2009-02-26 at 11:54 +1100, Smith, Michael wrote:
> >> "So, as I posted several times back in November and December, I was
> >>
> >> Matt is there some information you can point me to about how you would
> >> like the binary builds done? For example:
> >>
> >> * Is there a standard way of doing the compilation?
> >
> > Very much depends on your target. On, say, Debian or Ubuntu, the
> > standard thing is to build a .deb, following all of Debian's guidelines
> > for how to do that. There's a member of the Debian project who's job it
> > is to do this in such a way that it gets into Debian (and through Debian
> > eventually into Ubuntu) on a regular basis, so he's the obvious person
> > to ask to make test binaries happen for Debian. We might want to take
> > more control of this process and add the .deb rules directly to our
> > source.
> >
> > Similarly for Fedora.
> >
> > No idea about how things work on *BSD or Solaris. In Windows and OSX
> > land, there are these installer thingies..
> >
> 
> I now have a script that clones off a fresh copy of the repo and
> builds an installer for windows.
> 
> >> * Which repository should be built?
> >
> > Ideally both tip and stable, possibly crew.
> >
> 
> My script takes the repo url as a parameter, so it could easily build
> any repos we want.

Great. Please post it. It's not clear who'll eventually take charge of
this. Lee has historically been in charge of packaging Mac and Windows,
but I'm not sure where he's at. Steve Borho, as the packager of
TortoiseHg, is an obvious second choice, and he seems to be working
right now on automation too.

> >> * How should the results of the build be reported back to the project?
> >
> > Ideally a pointer to a directory of recent automated builds.
> >
> 
> I think the mercurial community would be better served if we had a
> central website where all the different builds were brought together.
> Additionally, I know I can spare the cpu cycles for builds, but I
> don't know how much bandwidth I can spare.

My priorities here are (in descending order):

- builds are made available for testing before release
- builders are responsive to feedback
- build processes are well-documented and repeatable by third parties
- builds are automated and regular
- builds cover all major platforms
- builds integrate well with TortoiseHG and existing Python installs
- build scripts are part of the main repository
- builds are all hosted in the same place

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list