Feature request #2370
Native and faster compilation of Python bindings
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Martin Dobias | ||
| Category: | Build/Install | ||
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Easy fix?: | No | Copied to github as #: | 12430 |
Description
The attached patch cleans the way how python wrappers are compiled. Until now, the compilation was driven with custom generated makefiles that didn't integrate well with CMake.
The patch uses macros from PyKDE project that make compilation native in CMake. The configuration is cleaner and it's possible to use multiple jobs (e.g. make -j3). Additionally the compilation runs several times faster: SIP is configured to generate only few (big) files instead of 100+ files (one for each class) - the compiler has to parse the headers fewer times.
Tested on linux (ubuntu). Before applying to trunk it should be confirmed that it works with other platforms.
pyqgis_cleanup.diff 
(47.2 KB)
pyqgis_cleanup_addendum.diff
(423 Bytes)
History
#1
Updated by Martin Dobias over 14 years ago
Added a small change I've missed... apply also pyqgis_cleanup_addendum.diff
#2
Updated by Jürgen Fischer over 14 years ago
Works with minor changes for the MSVC build:
cmake/SIPMacros.cmake:
< FILE(APPEND filename "")
> FILE(APPEND ${filename} "")
python/CMakeLists.txt:
> IF(MSVC) > ADD_DEFINITIONS(-DNOMINMAX) > ENDIF(MSVC)
<pre>
#3
Updated by William Kyngesburye over 14 years ago
Works on OSX (10.6, system python 2.6, SIP 4.9, PyQt 4.6). It does seem to compile faster.
I need to take a closer look to see how well it will work in the Xcode project. Right now I just run the configure.py and make, instead of using Xcode compilation (too hard for this case). Looks like configure.py is dropped. It would be nice if I can now make the Xcode project generate the sip sources and compile, then compilation can benefit from progress feedback and multicores.
#4
Updated by William Kyngesburye over 14 years ago
P.S. I wonder if the new findSIP could use the same Cmake variable names as the old one? This would make current build instructions still usable (OSX uses SIP_BINARY_PATH, now SIP_EXECUTABLE, to specify SIP).
#5
Updated by Martin Dobias over 14 years ago
Juergen, thanks for testing and providing the tweaks. I'll apply them when committing the patch to trunk. I'm just wondering why it needs the -DNOMINMAX definition... maybe it should be fixed elsewhere?
William, thanks for the feedback. Original variable names can be preserved, there's no problem with it.
#6
Updated by Jürgen Fischer over 14 years ago
Replying to [comment:5 wonder]:
Juergen, thanks for testing and providing the tweaks. I'll apply them when committing the patch to trunk. I'm just wondering why it needs the -DNOMINMAX definition... maybe it should be fixed elsewhere?
<pre>
#7
Updated by Martin Dobias over 14 years ago
- Resolution set to fixed
- Status changed from Open to Closed