[Qgis-developer] Merge of refactoring branch

Tom Elwertowski telwertowski at comcast.net
Sun Jan 7 05:26:35 EST 2007

Martin Dobias wrote:
> today I've ported all commits from trunk to Lib-refactoring branch, so
> it gets ready to be merged back to SVN. I'd like to ask you if you
> won't mind to merge it tomorrow.

I'm in favor of merging sooner rather than later but am concerned about 
the new build process.

If CMake is required, I'd like to hear the experience of some other 
developers using CMake and the Lib-refactoring branch. A new build 
process should be tested by several people on several machines before 
being rolled out.

I haven't used either CMake or the branch before so I downloaded both. A 
clean download doesn't build. In src/app, qgsmapserverexport.cpp doesn't 
compile due to a missing ui_qgsmapserverexportbase.h. My guess is that 
qgsmapserverexport.cpp doesn't belong here. Removing it caused the build 
to continue and the link succeeded. The right solution might be 
something else however.

The next issue is that qgsconfig.h is being constantly regenerated and 
the whole compilation restarting from the beginning. Initially, there is 
probably going to be a variety of build adjustments and it shouldn't be 
necessary to rebuild everything to do these. The autotool build knew 
enough not to rewrite files unnecessarily.

> To build it, you will need CMake (version 2.4 or preferably later). It
> has been tested and builds and runs well under Linux and Windows. I
> have no access to Mac, so I couldn't test there. I'm all for using
> CMake as the only make system as it's universal, flexible and easy to
> understand.

There are several Mac-specific issues.

1. In the autotool build, PREFIX was not defined for the Mac. The intent 
is to have a compile-time error if PREFIX occurs in code used by a Mac. 
How can PREFIX be removed from qgsconfig.h for the Mac?

2. On a Mac, Qt3Support requires QtSql. CMake doesn't figure this 
dependency out for itself. I was able to complete the build by editing 
two dozen generated files. What is the right way to handle this?

3. Main programs attempt to link against libutil which doesn't exist on 
a Mac. Again, I edited three generated files but it needs to be removed 
some other way.

4. The plugins are built as libraries (.dylib) rather then plugins (.so).

5. Is there a way to specify a search path for finding dependent 
libraries? I have multiple versions of libraries and the build process 
selected an incompatible set from a variety of locations. I had to edit 
all but one library path before I could build. For whatever reason, 
/usr/local, which has a complete and consistent set of libraries, was 
the least favorite place to search.

For many of these issues, I need to learn CMake and conditionalize the 
build process. The Mac problems shouldn't be a cause for delaying the 
merge but it would be good to hear that the new build works on a few 
developers' machines before moving forward.

Another possibility may be to do the merge now, temporarily update the 
autotool files to match the new directory structure and use the two 
build systems in parallel for a few weeks before retiring the autotool 


More information about the Qgis-developer mailing list