GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
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 for SConstruct script. Build now properly detects MinGW and finds dependencies correctly.
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.
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.
Properly Initialize mingwbuild variable.
MinGW support for SConstruct script. Build now properly detects MinGW…
… and finds dependencies correctly.
Added singleton unit test to check for multiple instances across mult…
…iple dynamic libraries.
Updates for supporting 64bit MinGW build on Windows 7+ via GNU tools.
Final MinGW 64 bit enhancements for Windows 7+ and Server 2008+
Updates to resolve issues after rebase from origin master for MinGW. …
…Added a few additional exprts and template library dependencies for GCC 4.8.1.
Reordered dependencies in correct link order and added graphite2
Environment clone required.
Environment clone failed to carry over in rebase. Added back in.