[Qgis-developer] CMake and python build now happy

[Mark Coletti]

I've discovered the cause of my build problem -- I had set the CMake
LIBRARY_OUTPUT_PATH to $HOME/lib, so all generated libraries were
being placed there instead of within the build directory hierarchy.
This is why make couldn't find the libraries.  qgis HEAD now builds
and runs properly.  (Including finding all plug-ins and icon files.
Huzzah!  Looks spiffy, too.  Now to play with the python bindings.
*squee*)

I'm wondering if maybe a little CMake refactoring would be useful?  I
inferred from previous threads on this topic that the CMake conversion
is still in flux.  Hopefully a CMake newbie such as myself will be
helpful in guiding such a refactoring.

So, given:

User-Agent: experienced software developer, familiar with make
            systems, but new to CMake (knows enough to be dangerous,
            and not enough to almost guarantee Bad Things Will Happen)

Use-Case: build and install system in a target directory; under
	  autoconf systems, this would be set via the configure
	  ``--prefix'' argument, in CMake use CMAKE_INSTALL_PREFIX

Here's a likely scenario (indeed the very one I fell in):         

The user-agent will likely skim TFM for basic CMake instructions and
peruse both the distribution based install instructions and those
found in ancillary sources, such as web sites.  (E.g., the useful
Wiki.)  The user-agent desires to set the install prefix, and notes
that the basic install instructions at
http://wiki.qgis.org/qgiswiki/Building_with_CMake describe the
environment variable CMAKE_INSTALL_PREFIX to set install target
hierarchy.  However the user-agent will _also_ note the ccmake curses
based command, and will use that just to see all the possible build
options.  There, the user-agent will see the shiny LIBRARY_OUTPUT_PATH
and set that, too, though will be puzzled at the redundancy.


				 ###

So there are two choices here:

1) Hide LIBRARY_OUTPUT_PATH from user configuration since it's use
   _will_ break builds.  I understand, perhaps mistakenly, that this
   is possible based on previous correspondence.  Essentially follow
   Scott Meyers' principle of making it impossible for a tool to be
   improperly used.

2) Keep it, but document it what it is for and possible use scenarios
   (e.g., maybe installing library binaries for different binary
   platforms); ensure that its settings are propagated properly
   throughout build process so that the correct modified library
   locations are used instead of defaults.

Which-ever path is selected, natch, make sure that the Wiki is
updated to deal with this scenario.

				 ###

I hope this helps!

And now off to learn more about the (hopefully happy) marriage of qgis
and python.

Cheers,

Mark