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. On Tuesday, 3 February 2015 18:21:00 UTC, Crispy Zeal wrote: > > 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. > > On Monday, January 26, 2015 at 3:40:24 AM UTC-5, Saúl Ibarra Corretgé > wrote: >> >> 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. >> >> On 01/24/2015 09:31 PM, Crispy Zeal wrote: >> > 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? >> > >> >> 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 >> <http://www.google.com/url?q=http%3A%2F%2Fsphinx-doc.org%2Fbuilders.html%23sphinx.builders.htmlhelp.HTMLHelpBuilder&sa=D&sntz=1&usg=AFQjCNHRf6vr4pTb2zm31L_YotOcoKOiKg> >> >> >> 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 >> >> >> -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
