Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

MinGW support #1800

Open
wants to merge 8 commits into
from

Conversation

Projects
None yet
2 participants

MinGW support for SConstruct script. Build now properly detects MinGW and finds dependencies correctly.

Owner

springmeyer commented Apr 5, 2013

This includes too much hardcoding to be accepted. Things like python mingw-shell-adapter.py should be passed in as configure arguments to prepend to the pkg-config calls. But, do you even need this? I recently added the HOST argument as a first step towards cross compiling. Set it to any value and it will skip the configure checks.

Owner

springmeyer commented Apr 5, 2013

Also, why change all the path defaults from /usr/* to $PREFIX? This will break unix builds because then by default /usr/lib will not be on the linker commands where likely critical system libraries are that need to be linked. On my OS X machine, for example, my build then fails with the inability to link the standard c++ library.

You should be able to pass in the necessary configure options on the command line to set up the custom paths needed for mingw, right?

Also, why change all the path defaults from /usr/* to $PREFIX?

Because the prefix setting is currently getting ignored. What Unix systems are you worried about breaking? Most of the dependent libraries Mapnik uses include a autoconfigure script which take a '--prefix' option. This prefix option is used for referencing the standard locations for all the includes and libraries. The prefix value is also, more importantly, used for cross compiling. For example, on some systems, you will find includes and libraries under /usr/local or --prefix=/usr/local. In MinGW 64bit, the accepted dev environment has them stored under /mingw/lib, --prefix=/mingw. If cross compiling on Mac OS X for PPC or I86, you would see --prefix=/usr/local/ppc, --prefix=/usr/local/i386, or --prefix=/usr/local/x86_64.

This includes too much hardcoding to be accepted. Things like python mingw-shell-adapter.py should be passed in as configure arguments to prepend to the pkg-config calls. But, do you even need this?

Yes, this is needed on MinGW for a variety of reasons. First, Scons TryAction command doesn't understand the bash shell on windows. You have to wrap your command using this python script, otherwise, the command will fail. For example: pkg-config will not be found or executed correctly. Secondly, Scons doesn't understand MinGW paths because the the project decided to rewrite the python lowlevel file API. They modify the include settings provided to gcc and prepend drive letters to path values. It's very frustrating. More details can be found in this ticket: http://scons.tigris.org/issues/show_bug.cgi?id=1500 . I've even contributed to the dialog. Not sure what will come of it.

I recently added the HOST argument as a first step towards cross compiling. Set it to any value and it will skip the configure checks.

I'd much rather have it detect and use the proper locations for dependent libraries. It should be relatively trivial. Most autoconfigure scripts take care of this. However, it seems like the absence of an autoconfigure script has already contributed to much of the dependency detection being hardcoded in the Scons construct script. My command-line variables are already getting kinda lengthy:

$ ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --build=x86_64-w64-ming w32 PREFIX=/mingw CUSTOM_CXXFLAGS=-DMS_WIN64 BOOST_INCLUDES=/mingw/include/boos t-1_53 BOOST_LIBS=/mingw/lib CC=x86_64-w64-mingw32-gcc-4.7.2.exe CXX=x86_64-w64 -mingw32-g++.exe HOST=MinGW

I would prefer not to continue to append environment variables to the script just to get it compiling on a platform it should be able to detect on its own. Although, I admit, I don't have that much exposure with Scons as it's not widely used.

Either way, I'll try to update the script more to your liking. However, I'm not certain passing all the platform related configurations and workarounds as variables is an appropriate way to go. I've got to break here for a second, but I can talk more later. Anyways, feel free to provide any additional details. THanks!

Rebased the changes. Should be in sync with master now. Geos has been completely removed too. Let me know if there's anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment