CPack packaging instructions

[scunz]

This PR tries to setup working install and packaging rules.

I've priorized this over splitting the repositories in a sane way; on that road, I found a way to accomplish the differences in using one of our libraries and building it on its own. Though, I did not yet enforce good behaviour for the stand-alone build scenario.

Qt	Action	Mac	Linux	Win64	Win32
4	build	:+1:	:+1:	:+1:	:question:
4	make install	:+1:	:+1:	:+1:	:question:
4	cpack	:+1:	:question:	:+1: :-1:	:question:
5	build	:question:	:question:	:question:	:question:
5	make install	:question:	:question:	:question:	:question:
5	cpack	:question:	:question:	:question:	:question:

The macpack branch of all submodules is required (There's just a one line change in each).

Each OS has now an overall block of cmake code, where such one is required. Actually, I didn't find may places where Mac OS X, general Linux and Windows share a single bit of semantics. This is driving me crazy; and I already got the feeling that what makes this code works at all is truely witchcraft.

Also, I tried to mimic the installed-state in the build directory as much as possible. I guess nobody wants to develop something and then figure out: Oh, the installed software uses so much different file system layout that nothing is working anymore...

As a consequence, this means: We're building frameworks and an app bundle and put it workingly together already at build time. The result is an app-bundle that (unlike the installed one) only lacks external dependencies, but is still able to work on its own.

This - more or less - broke all other build systems. At the end of the day, this PR is a rewrite of quite everything in mgv related to installation or build-tree layout.

Furthermore, I figured out, that every change requires to re-test everything: 2 tool sets * 3 Operating Systems * 2 CPU-Archs = 12 * 10 minutes for compiling, installing and manual execution. So in the end, I hope this PR will lay a foundation that makes all of this more easy.

There are some issues still:

• Qt 5 I've not tested any of this against Qt5 yet.
• 32 bit builds on Mac OS X, Linux and Windows In general, I'm trying to avoid those as much as possible. Compiling Qt4 + 5 on 3 operating systems will take a while and I'm pushing this back until I know at least that the 64 bit versions work.
• libgit2 This one is really bothering me. On Mac OS X, the public includes and library are installed as public interface into the bundle. Looks weird. Also it's not a framework - as a result, it needs to be fixed up before being at the correct location in the bundle (We can't tell the libgit2.git submodule what to put into the CMakeLists.txt file, thus not alter the build position). This isn't stopping a "just" compiled MGV from running, though. On Linux, when installing, I put all private things, well, "private". That's not true for the headers, pkgconfig files et al comming from libgit2. Those are boldly installed into $PREFIX/include. This would very much interfer with a system-installed libgit2. Not nice either. But as there is no published and readily available libgit2 version on any linux distribution, we still have to bundle it into libGitWrap, probably for at least one or two years. On Windows everything seems more smooth. Nothing interfers with something else - as there will probably never be a windows-system-libgit2. However, the installed headers and .lib files are annoying. Another Windows issue is, that fixup_bundle doesn't find libgit2.dll correctly. I'm not yet sure what this is related to, but I think it's because I can't add the directory where libgit2 is built to the INSTALL( CODE ... )-Section that deals with fixup_bundle. But I cannot redirect the libgit2-build location unless I either rework the complete build system once again or tweak libgit2's root CMakeLists.txt file.
• fixup_bundle Due to no available manifests (and in fact license restrictions from Microsoft), works only with release builds. Not a big deal (who wants to distribute debug packages anyway) - but it's worth mentioning. This is a problem, because it required me to skip the inclusion of debug plugins to qt. This should have been done anyway, but the debug-suffix on windows is different from the one used by Qt in Mac OS X. Luckily on Mac OS X, the right libraries are picked up automatically and the debug ones are ommited. On linux, it says that no fixup is required. Well, this is some kind of joke, probably. The truth is: Via the target property INSTALL_RPATH everything that would later on need to be fixed up has to be corrected in advance. This is another reason for wanting to setup the build-tree as much compatible to the install-tree.
• cmake itself During the install phase, cmake executes the macros inserted via INSTALL( CODE ... ) before it dives into subdirectories. This is bad, because half of the installation instructions had to be moved out of the root CMakeLists.txt and cannot be put there (Even after my desired build-system splits are done). The other half has been moved into src/Main. That's the only other place where the final executable target should have been defined.
• Qt on Mac I have a self-built Qt4 and one built from MacPorts. Compiling mgv against either of them results in CPack adding the system-libraries libcrypto, libz, libssl into the bundle. I'm totally unsure if this is neccessary (And actually think there's legel issues with distributing binary crypto software).
• Linux And another issue is, that I don't use any binary distributions of linux. I have no way to test RPM or APT packages at all. Think this will require me to setup a few virtual machines.

And when we're at it: Do we care to support any of FreeBSD / NetBSD / OpenBSD / Solaris? Will we ever require MGV to run on Android and/or iOS? This boils more or less down to: How relevant will those systems get on boxes with real screens and conventional input methods? I'm really looking forward to the days when I will be able to review a pull request using the front panel of my vaccum cleaner...

[scunz]

@antis81 What do you think about this?

It's unfinished and the result on Windows is quite less than even unsatisfing. But I think, that I'm going to merge this anyway. Since I've setup CMakeLists to do our own build style for libgit2, this again is executable on windows (even the make installed version) and gets the deps right for the mac bundle. I feel like it's the best I can do right now. Getting it really right seems to be a longer road...

[antis81]

Yeah, I've followed the progress a little and think it is quite pleasing. At least I do not know how to do it better by now. I'm just excited about the OSX package. Hopefully we can get it into apt and yum some day, and maybe homebrew. Personally I do not care too much about the windows versions, but that is the most challenging part to get it really crossplatform. Feel free to merge! It can get only better :smile:.

[scunz]

As far as I remember, whereever some "usable" code appears, you usually dont have to wait long for someone who creates debian packaging files for it. So, let's aim for that :-)

The really challenging part was to get the Mac OS things right. But that may be subjective and due to my lack of previous expierence.

Then let's get this in, soooish.