CMake related patches.

[Dirk Hohndel]

OK, here's where we are with this.

a) I cleaned up the patches a bit, reworded every(?) commit message and
   pushed them out
b) I found a bug (typo), fixed that and pushed it out
c) I think part of the FIND_Lib... logic is off: you search
   ${CMAKE_CURRENT_SOURCE_DIR}/../install/include
   ${CMAKE_CURRENT_SOURCE_DIR}/../libdivecomputer/include/
   but those directories should be relative to the build path, not the
   source path, I think. Here's why:
   ~/src/subsurface
   ~/src/libgit2
   ~/src/libdivecomputer
   ~/src/.....
   ~/win/win32/subsurface (out of tree build of the sources mentioned before)
   ~/win/win32/libgit2    (ditto)
   ~/win/win32/libdivecomputer
   ~/win/win32/install

   So while what you created with the CMAKE_CURRENT_SOURCE_DIR works well
   if you have something like this:
   ~/src/subsurface
   ~/src/subsurface/build
   ~/src/install
   ~/src/libdivecomputer (with an in tree build)
   it fails in the more generic scenario above.

First I thought "hey, this is a chance to have one single supported way of
doing things and make everything follow that lead". Turns out that's really
hard and we almost certainly would end up with something quite inflexible.

But maybe we can reduce it to two supported structures?

Instead of grabbing the include files and libraries out of the source
directories like we have done it in the past (and I'm the one who started
to implement that and who made it worse and worse with coming up with
different hackish ways to implement this for the various build scenarios),
can we agree that for all the "build from source" libraries we'll do a
side install?
So everthing is either in
${CMAKE_CURRENT_SOURCE_DIR}/../install/{lib,include}
or in
${CMAKE_BINARY_DIR}/../install/{lib,include}

This way people who prefer the ~/src/subsurface/build style setups get
something that works and people with a setup like I described above get
something that works.

And we do away with all the hackish ${some_path}/libdivecomputer/src/.libs
things and even worse with the crap fake install I have been doing for
libmarble. Which brings me to the one big problem with this. Marble
doesn't have a simple target to install the just libssrfmarble.* and all
the include files.

Can someone who speaks better cmake than I do add a patch that adds a
custom install target to our Subsurface-testing branch of Marble?
Basically I want a target that respects ${CMAKE_INSTALL_PREFIX} and fills
lib and include under that with the right files.

OK - what am I missing? Are these good ideas? Is there a better idea?

I really want to get it right this time and then stop worrying about build
tools and the way I build the binaries for Windows, Man and the half dozen
flavors of Linux we support...

Thanks

/D