0 votesclick to vote up

David Sugar: Ubuntu, MinGW, and GIT vendor repositories Published Sep 6 2012 via RSS

planetUbuntu

It has been known that I tend to do some cross-platform development, including for software that runs on Microsoft Windows.

For me the most logical approach has been to make use of MinGW (Minimal GNU Windows), a set of GNU tool chains, GCC compilers, and tools that have been adapted for compiling applications for Microsoft Windows. However I do not use these on Microsoft Windows, and do not run it even to develop or build applications. I do not even have it on any machines, real or virtual. Instead I use it on Debian (or Ubuntu) hosted systems as a cross-compiler environment.

The GNU MinGW tools for cross-compiling have been present for a long time in Debian (and Ubuntu). The present form is installed with mingw-w64-dev, and supports building applications for both 32 and 64 bit windows. Fedora also includes a version of MinGW. In their case, they not only package the cross-compiler, but also common free software and related support libraries, which can be installed to provide a more complete environment. There is a PPA out there that does the same for Ubuntu. I am however not so sure this is a great idea. What I do instead is cross-compile a common set of free software libraries out of a vendor branch repository that has versions I can test and maintain.

The concept of a vendor branch is that one takes an existing external (3d party) library produced elsewhere and imports that into a local repository. One can then track local changes needed for something different (such as mingw cross compiling). Since the base of the tree is an import of an upstream release, one can easily create and submit patches back to an upstream when appropriate.

I use git for vendor repositories. While there are different strategies to do this, for me the simplest was to create a bare repository, and then only push and store tags in it.

If I want to make a repo for version 5.0.0 of libfoo, I would create a repository, locally create an import branch, and tag it something like v5.0.0-original. This tag then gets pushed. If I want to do some changes, I can create a temporary work branch locally in git, do the changes, and then create a new tag, like v5.0.0-patch1, and then push that new tag to a remote vendor repository. If I want to submit a patch upstream, it is as simple as using git to diff between v5.0.0-original and v5.0.0-patch1.

So a new 5.0.1 release comes out. This too I can import into the same repository, using a new temporary local branch, and import in a new tag, v5.0.1-original. In theory I can then apply the changeset between v5.0.0-original to v5.0.0-patch1 to it to get any patches/changes I found needed for local builds, and save that as a new tag, v5.0.1-patch1, as well.

So far I have been able to rebuild most libraries one finds in a GNU distribution for application development, including Qt. In the case of Qt, I was able to create new spec files that explicitly support cross-building mingw32 hosted on Debian and then use Qt's own configure to generate appropriate makefiles. I also have been looking at wxWidgets a lot more.

Building on MinGW32 hosted on Debian (or Ubuntu) provides a much saner way to develop software for Microsoft Windows. Where Microsoft never really developed a concept for a standard shared place to store common libraries and headers, and I think this is because even the basic philosophy of code sharing seems not to be in their genes and certainly not in their development tools, I can organize one on my box and pass it with configure flags to builds.

Since I also use nsis (also packaged in Debian and Ubuntu) to make pretty graphical installers for applications for windows, and wine for testing, this means I can build applications for users of that platform without ever having to have a license or any other legal instrument with Microsoft, whether for their development tools or operating system, and this too I am happy about. We can build free software for that platform using entirely free as in freedom tools and operating systems. These can never be taken away, nor enable false legal harassment that any form eula with them can permit.