[Qgis-developer] Merge of refactoring branch

[Martin Dobias]

Hi Tom,

On 1/7/07, Tom Elwertowski <telwertowski at comcast.net> wrote:
>
> 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.

as far as I can tell, some devs have built it successfully since I've
assisted them with initial problems.

> 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.

This must be caused from yesterday's porting from trunk -
qgsmapserverexportbase.ui has been removed from Makefile.am so I've
removed it also from CMakeLists.txt, but haven't tried clean install.
The right way is not to build qgsmapserverexport.cpp too as it's not
being used anymore. I'll fix it.

> 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.

qgsconfig.h should be regenerated only during configure. Does it mean
that every time you try to compile it builds all source files again?
Maybe the problem is with writing qgssvnversion.h ?

> 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?

It shouldn't be a problem to #ifdef PREFIX in qgsconfig.h.in so it
won't be defined.

> 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?

This might be fixed by adding this to CMakeLists.txt in root directory:
IF (APPLE)
  SET (QT_USE_QTSQL TRUE)
ENDIF (APPLE)
However this should be handled correctly by the FindQt4 macro from
CMake, so it might be worth reporting that.

> 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.

Here I don't have any idea what's wrong :-/
Is that CMake which adds libutil for the executables automatically or
does one of these variables specify it?
QT_LIBRARIES
PROJ_LIBRARY
SQLITE3_LIBRARY
GEOS_LIBRARY
GDAL_LIBRARY

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

I don't understend well Mac libraries, but I guess this might be fixed
by setting second argument of ADD_LIBRARY() to MODULE instead of
SHARED for the plugins and providers.

> 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.

This is possible - in cmake/ directory there are several files for
detecting dependency libraries. In FIND_PATH and FIND_LIBRARY commands
you can set preffered order of search. Looking at them I see that /usr
and /usr/local paths are in wrong order - first should be /usr/local
...
I can fix that...

> 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.

I'm not a fan of the idea to leave (althogh just temporarily) both
build systems at the same time - IMHO it will just shift fixing build
issues to a later time as people will still try to use autotools...

Martin