[Qgis-developer] Merge of refactoring branch

[Tom Elwertowski]

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

Every .o file in build.make seems to be dependent upon flags.make which 
is regenerated whenever I modify CMakeLists.txt. ccache bypasses the 
actual compilation but many files are reprocessed.

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

This solves the problem.

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

util was being appended to PYTHON_LIBRARIES in CMakeLists.txt. I changed 
the test to UNIX AND NOT APPLE.

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

I will try MODULE; libtool was using -module. If it doesn't work, I will 
look at what -module expands to and see if I can add it directly to the 
link flags.

I can now build QGIS/Mac but plugins/providers all fail to load.

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

There is a CMake variable CMAKE_FIND_FRAMEWORK which defaults to FIRST. 
Setting it to LAST does what I want for now. Eventually, it should be an 
qgis Mac build choice. I have a complete set of libraries in both places 
and might want to use either. My first try however, was behaving as if 
set to RANDOM - not a documented option :)

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

I can now do a complete compilation but the installation is very 
strange. As I discovered with the CMAKE_FIND_FRAMEWORK variable, CMake 
is doing path substitutions which I need to understand. In a pure Mac 
application, all libraries would be in /Library/Frameworks rather then 
/usr/local/lib. For both finding things and installing things, CMake is 
sometimes using a path as is and sometimes deciding to prepend or 
substitute or append some other Mac path.

It's nice to have the previous build system working so that I can do 
something else for awhile when making no forward progress on the new 
build sstem. I can run qgis/Mac if I manually rearrange the installed 
files so perhaps I won't resurrect the old build files if can get 
plugins to load.

Tom