Help Wanted : QGIS Native Windows Build

So some of you may know that I have been working on a native Windows build for QGIS. It uses Mingw and Msys compiled dependencies. This is to provide and alternative / replacement build environment for the chrooted cross compilation process under Linux. By creating a native Windows build environment we hope to attract mode QGIS devs who are more used to working on the Windows platform. AS you may have seen from my previous posts things are going quite well, with the core libraries and drivers building and my native build able to render basic raster and vector layers. However there are still a few things to sort out so I thought I'd post a 'help wanted' list:

  • Build GRASS in the msys environment
  • Build Postgres libpgfe in the msys environment
  • Build QGIS GRASS provider and plugins
  • Build Postgres provider
  • Build GPX support
  • Check help viewer is working
  • Test mapserver export
  • Get rid of the hacks in my build notes (see below)
  • Bundle in some nice (small!) datasets including the Alaska data - perhaps as separate installers? It would be nice to have a few different ones. All you need is basic knowledge of NSIS or BitRock
  • Check the installer - does it remove all files properly? Does QGIS run on all machines ok when installed using it? etc

For those of you itching to get started :-) I've included a copy of my build notes for Windows below.



Procedure for setup of a windows build environment for QGIS

Tim Sutton and Godofredo Contreras 2006
With thanks to Tisham Dhar for preparing the initial msys environment



This document describes the process you need to follow to get QGIS built directly under windows (rather than using a cross compiler under linux).

Note: The process for building under windows is still being sorted out so check this document regularly for updates.

Note: This document is available in QGIS subversion as READM_WINDOWS.txt

Msys

Get this :

http://qgis.org/uploadfiles/msys/msys.zip

and unpack to c:\msys

The file is compressed using zip - you can get a free windows application for creating and decompressing zip files here:

http://www.filzip.com/

Note: its a big (200mb) archive - it will take a while to unzip!

Qt4.2:

Download qt4.2 opensource precompiled edition exe and install (including the download and install of mingw).

Edit C:\Qt\4.2.0\bin\qtvars.bat and add the following line (the second is only needed if you like vim in your shell):

set PATH=%PATH%;C:\msys\local\bin
set PATH=%PATH%;"c:\Program Files\Vim\vim70\

NSIS:

Downlad and install NSIS from (http://nsis.sourceforge.net/Main_Page)

GDB:

Download and install gdb-6.3.2.exe from

http://sourceforge.net/project/showfiles.php?group_id=2435

and install into c:\mingw

QGIS:

Check out to c:\dev\cpp\qgis
Currently you need to put it into that location I think - if you try to build somewhere else you *may* run into problems - particularly with the NSIS installer as I havent checked all paths are relative yet.

Next you need to shift some files around. Note I expect this requirement to go away once the windows build process is refined a bit.

Core:

- moved qgsspatialrefsys* and qgscoordinatetransform* into core dir from gui
- qgsspatialrefsys.cpp - commented out lines using qgsproject as it depends on gui stuff
- qgsdistancearea.cpp - commented out lines using qgsproject as it depends on
gui stuff and moved to core
- qgscsexception.h into core from gui (only tested on mac)

I have created a small archive which includes the above changes, which I will make available.

Gui:

Temporarily disable postgres support until we heve resolved issues
- added #undef HAVE_POSTGRESQL to qgisapp.cpp around line 144
- added #undef HAVE_POSTGRESQL to qgsvectorlayerproperties.cpp around line 32
- moved qgspluginregistry.* to gui from core

Building:

Now open the qt command shell

cd c:\dev\cpp\qgis
qmake
make

Create the installation package:

Download both the QGIS debug and release installer packages from

http://qgis.org/uploadfiles/testbuilds/

and install them. Now copy the installation dirs from C:\Program Files\QGIS* into
c:\dev\cpp\qgis\qgis-debug and c:\dev\cpp\qgis\qgis-release respectively. After
making these copies uninstall the release and debug versions of QGIS from
your c:\Program Files directories using the provided uninstaller. Double check
that both dirs are complete gone under program files afterwards.

Now using windows explorer, enter the c:\dev\cpp\qgis\win_build directory and right
click on qgis.nsi and choose the option 'Compile NSIS Script'. Do the same
for qgis-debug.nsi. Congratulations you should have two installable qgis
setup files in the win_build directory now..

QGIS Native Windows Build

I've only just started looking at developing with/for QGIS on Windows and was wondering about the effort going into a native Windows build with msys. I followed the instructions for building with Visual C++ .Net Express on the wiki and have a build environment that 'just works' without using msys. What are the pros/cons of doing it this way?

Pros and cons of visual C++ express build

Hi

For me the biggest pros of doing it the qmake + msys way are:

  1. Qt4 open source under VS C++ express is not formally supported
  2. the msys + mingw approach provides a build environment that is very familiar to linux developers
  3. although the operating system is non free (as in freedom) software, the rest of the toolchain is
  4. we can use gdb and dr mingw for debugging (once again nice for linux heads)

As you can see, the above list exhibits a strong personal bias towards the unix way of doing things. Since I am on more familiar turf its easier for me to cope with unexpected issues that prop up. VS Express is a complete twilight zone to me so if something goes awry its more work for me to resolve the issue. That said I'm game to give the VS Express route a go if it can actually build a complete implementation of QGIS.

So let me return a couple of questions:

  1. Are the wiki notes still up to date?
  2. How complete is your build? Does it have grass + postgis + gpx etc support?
  3. If not do you forsee any problems getting these parts built under express?
  4. Are you interested in maintaining a VC Express build environment that can be used by other like minded developers?
  5. How do you feel about the VC Express license? Are there any caveats that will come back to bite us on the bum later?

It would be good to be as inclusive as possible so having a maintainer / 'champion' for VC Express build environment would definately be a good thing!

Pros and cons of visual C++ express build

1. The only deviation from the wiki notes I had was to download the internet explorer part of the platform sdk: that seems to be a new requirement since the notes were written. Having said that, I had to modify some of the source to get it to work with QT4.2.
2. To be honest I've only tried the raster and gpx support as those were the only bits required for my current project. I can have a go with the other bits too.
3. At the moment I don't forsee any problems. I suspect if I attempt to build all the dependencies (gdal etc.) I may have problems.
4. Yes, I can give that a go. The current setup needs a bit of tidying with regard to .pro files. Do you know if there's much demand for that or are most folk happy with the msys approach? I'm guessing that anything that works with the Express version will also work with the other editions of Visual Studio...
5. I'll need to have a look through the license to see if there's anything restrictive in there. The main reason for the original question was that I wasn't sure about the licensing implications of the patch I applied to QT to get the visual studio support.

Basically what I have at the moment is a two week old version of 0.8 preview 2 from SVN that builds and runs without error that will also load a raster and a gpx file.

Pros and cons of visual C++ express build

I've had a look at the current VC++ solution I have and it's missing all providers bar the delimited text and ogr ones. I guess it still needs some work...

Thanks for the feedback

Hi

Ok thanks for the feedback on this. I guess for now (0.8 release) I'll continue focussing exclusively on the mingw approach. I'll come back to the VS Express environment in the future though.

Best regards

Tim