Windows installers for libuv binaries

[Crispy Zeal]

Hi,

Many cross-platorm libraries provide a Windows installer for developers of that platform, provided by either external parties or as part of the project. It's really convenient for developers on Windows, because there isn't very much package manager support, and usually you end up linking to these binaries globally in your Visual Studios project anyways. These installers usually include documentation, headers, prebuilt static and dynamic libraries, debugging symbols, and sometimes the option to install source code. Some examples of libraries that offer this off the top of my head are OpenSSL, SlimDX, and GLFW, although I am sure there are countless others.

I think that libuv is a good candidate to provide an installer like this. Firstly, it adds some appeal to Windows developers, being able to quickly install and link their projects to libuv. Secondly, for developers who build and distribute libraries on top of libuv for use on Windows, it's a lot easier to tell one of your users to simply install the libuv development packages than it is to guide them through the process of building and installing libuv.  Personally, I'm interested in the second use case.

There's a lot of initial questions that arise about how libuv should approach this issue. Should it be internal to the project or should we rely on an external source to provide these packages? Should it be a full-fledged installer like OpenSSL, or should we just provide a zip archive? What should be included in these packages, and how often should they be released? Many projects choose to distribute nightly builds. There definitely needs to be a discussion on all these details.

What do you think?

[Saúl Ibarra Corretgé]

Hi,

Thanks for bringing up the discussion here. I have been approached about
this in the past, hopefully others will chime in and we'll find some way
forward.

We can probably find something basic to start with and then complicate
it down the road if needed.

As a starting point we could bundle the headers, static library, dynamic
library and documentation. Looks like we might even be able to generate
a CHM file with it, if that's still what Windows folks are comfortable
with:
http://sphinx-doc.org/builders.html#sphinx.builders.htmlhelp.HTMLHelpBuilder

The main question is what compilers do we use to compile the libraries?
Visual Studio 201-what? How about MinGW / MinGW-w64? AFAIK we'd have
some trouble getting the 64bit builds, because we'd need the Pro version
of Visual Studio, right?

Then, assuming we have cleared all that someone would need to volunteer
the time / get some sponsorship and automate the process so that anyone
with a Windows machine (though the MinGW packages could be
cross-compiled on Linux) can do it.


Those are my 2 cents, cheers!

--
Saúl Ibarra Corretgé
bettercallsaghul.com

[Crispy Zeal]

Hey,

I think OpenSSL provides binaries for both MinGW and Visual Studios, so that's probably the way to go.

Visual Studios Pro is now available for free with the latest community edition. I heard that LLVM was bumping

up their requirement to VS 2013, and I don't think that's a bad idea. Visual Studios usually lags behind

compared to other compilers, so it's a good idea to stay up to date. Another option is to provide VS 2008

binaries if we really wanted to maintain compatibility, however. Some people provide several versions of

their packages for a few different VS versions. Honestly, I just don't see the need to do this, since the

community edition is free and all.

I'm not sure a CHM is necessary. A lot of projects will just distribute HTML documentation, and it'll probably

just get outdated if we build CHM files anyways. The less work required to build these packages, the better.

I'm mainly concerned with how we can automate this process and who's going to be responsible for it. Nothing

is worse than starting to release these packages, and then seeing them all get outdated. I may be able to offer

my time to assist with this.

[Luigi Grilli]

Hi,

In my opinion having VS builds would be a fair and good start. Of course you need builds for all the different versions. It's kind of useless if you provide a build just for one version forcing people to use that one.

I won't complicate it with mingw or cygwin builds, at least at the beginning.

I suggest you to have a look at appveyor.com. They offer a free windows build platform for open source projects.

In the past I tried to build libuv there and I managed to make it work so I can help on the setup if needed.

To package the artifacts I would use NSIS that in my experience always proved to be easy to use and really fast at install time.

I would honestly start with this and then add features depending also on feedback from the users.

There are also 2 .NET wrapper libraries available for libuv (one from me and another one from Andrius Bentkus) that could be packaged as well as a future added feature. 

[Roger Light]

Hi all,

I sent a pull request with support for building libuv on appveyor.com and producing an nsis based installer. The pull request is here:

https://github.com/libuv/libuv/pull/359

It's stalled there, so I'm reviving this topic for wider discussion. I'm not exactly an appveyor expert so would appreciate any comments on that side of things. Saúl, it seems as though you're suggesting that the current testing facilities already include Windows support, which is to be expected. Is there anything anyone in the community can do to help turn that testing infrastructure into something that also builds the installers?

Cheers,

Roger

[Saúl Ibarra Corretgé]

Hi Roger,

On 06/11/2015 10:50 AM, Roger Light wrote:
> Hi all,
>
> I sent a pull request with support for building libuv on appveyor.com
> and producing an nsis based installer. The pull request is here:
>
> https://github.com/libuv/libuv/pull/359
>
> It's stalled there, so I'm reviving this topic for wider discussion. I'm
> not exactly an appveyor expert so would appreciate any comments on that
> side of things. Saúl, it seems as though you're suggesting that the
> current testing facilities already include Windows support, which is to
> be expected. Is there anything anyone in the community can do to help
> turn that testing infrastructure into something that also builds the
> installers?
>

Currently the testing facility is provided by and ran by our nice
friends running iojs. They have enough on the their shoulders, and since
libuv binaries are not a requirement for iojs (it uses it bundled) I'd
rather see if we can achieve this with appveyor.

Running tests there is fine, as long as it doesn't add much noise. I'd
like to explore how the release making process would work, but I haven't
gotten around to do it yet :-(

There are a few Windows issues / PRs which I'd like to address for next
libuv release, I'll see if I can have a look at this as well.

Thanks for your efforts on this!

[Roger Light]

Hi Saúl,

> Currently the testing facility is provided by and ran by our nice
> friends running iojs. They have enough on the their shoulders, and since
> libuv binaries are not a requirement for iojs (it uses it bundled) I'd
> rather see if we can achieve this with appveyor.

Ah, I understand. That's a lot clearer.

> Running tests there is fine, as long as it doesn't add much noise. I'd
> like to explore how the release making process would work, but I haven't
> gotten around to do it yet :-(

The appveyor config doesn't do any tests, it just builds the binaries
and creates an installer. If the status of the build changes (success
<-> fail) then an email notification is sent to the github repo owner,
but that can be disabled.

For every each push that ends up in github.com/libuv/libuv (or
wherever) the build is triggered. I haven't found a way of it not
doing that. If the push includes a git tag, the tag name is used as
the installer version number and it is deployed to github, otherwise
it uses "1.5.0.{build}" as the version number and doesn't deploy to
github, but does save it.

It might be better to have the appveyor version number for non-tag
pushes set to something that wasn't related to a release so there was
less of a maintenance burden. "testing-{build}" or something perhaps.
Assuming the file structure doesn't change that should be it.

> There are a few Windows issues / PRs which I'd like to address for next
> libuv release, I'll see if I can have a look at this as well.

That would be great, it would make my life lots easier.

Cheers,

Roger