[Qgis-developer] Merge of refactoring branch

[Tim Sutton]

Hi Tom

For interest, are you building with Qt build from source or from the
Qt dmg they introduced this release?

Regards

Tim

On 1/9/07, Tom Elwertowski <telwertowski at comcast.net> wrote:
> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>


-- 
-- 
Tim Sutton

Visit http://qgis.org for a great Open Source GIS
Home Page: http://linfiniti.com
Skype: timlinux
MSN: tim_bdworld at msn.com
Yahoo: tim_bdworld at yahoo.com
Jabber: timlinux
Irc: timlinux on #qgis at freenode.net