Proposal for building Windows devlibs and for windows build environment setup
Dear Inkscape Team,
I have a proposal for improving the delivery for the windows libs and for setting up a build environment.
The current method of delivering binary libs has two disadvantages:
1.) it restricts the user to a very specific binary gcc build (at least the docs say so).
2.) it is tricky to check if this delivery method is GPL compliant. According to GPL if you deliver binaries you also have to deliver sources, and it is a lot of work to check all libs licenses and to check if all required sources are in the delivery. Please note that it is NOT sufficient to say "this is standard GPL software and you can download the sources from the official sources". If you delivery binaries, you have to deliver the sources.
Now to my proposal: for another open source project I created 2 scripts: one which automatically sets up a fresh cygwin with MinGW cross support and whatever else is needed and another one which downloads and builds a bunch of libraries and apps from sources, including GTK, cairo and pango. About 70% of the libs inkscape requires are built by this script, so it wouldn't be that much work to add the remaining 30%. This does not just setup a build environment and builds everything automatically, it also documents exactly what was used and how it was built (and possibly patched).
So my proposal would be to instead of delivering the libs as binaries and lengthy instructions just deliver these two scripts. The scripts are fairly simple and well documented. The build for inkscape and all its libs from scratch would likely be 2..3 hours on a decent machine.
Would others appreciate such a mechanism to build inkscape on windows? Usually it would be a single call to a DOS batch file to setup cygwin and start the download and build process.
Best regards,
Michael
On 31.03.2016 9:32, Michael Soegtrop wrote:
Dear Inkscape Team,
Now to my proposal: for another open source project I created 2 scripts: one which automatically sets up a fresh cygwin with MinGW cross support and whatever else is needed and another one which downloads and builds a bunch of libraries and apps from sources, including GTK, cairo and pango. About 70% of the libs inkscape requires are built by this script, so it wouldn't be that much work to add the remaining 30%. This does not just setup a build environment and builds everything automatically, it also documents exactly what was used and how it was built (and possibly patched).
So my proposal would be to instead of delivering the libs as binaries and lengthy instructions just deliver these two scripts. The scripts are fairly simple and well documented. The build for inkscape and all its libs from scratch would likely be 2..3 hours on a decent machine.
I did something similar (actually, still doing it, although it's been a year since i last updated my stuff), so here are some comments on this:
1) I would suggest MSYS2 to be used (instead of Cygwin), as a shortcut, as it cuts down the number of packages that need to be built. Using MSYS2 might also be faster (because compatibility layer will be thinner than Cygwin).
2) The build process can be automated, but there are some quirks to be aware of:
* some tools can crash (xsltproc, run by gtk-doc, crashes for me sometimes; this might or might not be isolated to a particular build/version)
* running with make -jN (where N > 1) can break some makefiles that don't have dependencies set correctly. Not all projects care enough to check that -jN works. Since building on Windows is slow (no frictionless fork()), -jN is useful. An aside: IME, installing Debian in a VirtualBox and cross-compiling from that Debian is faster than installing Cygwin/MSYS2 and [cross-]compiling from there (on the same machine).
* depending on how you set up the stuff, you might need administrative privileges to do some things the development tools do. If you use native symlinks, you *must* be admin. Some projects build binaries that have "install" or "setup" or "update" in their filenames, but don't bundle manifests with them - this causes UAC prompts to appear (or just prevents tools from working), unless you are already running as admin, thus breaking the automation. gtk-update-icon-cache is one example.
* fetching source tarballs can fail sometimes. Projects hostings are rarely down, but if you build 100+ packages, chances are that one of the tarballs is unavailable. This is especially bad for perl (luckily, you most likely won't need to build perl)
* Cygwin (and, by extension, MSYS2) has BLODA, which can break stuff in unexpected ways. I once had graphics card drivers interfere with the build process. True story.
participants (2)
-
LRN -
Michael Soegtrop