[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
system.
Tom
More information about the Qgis-developer
mailing list