Add cmake build system

[Bjoe]

First POC commit for issue #53

Some files are copied from Poco project.

The interesting part are in macchina.io/platform/OSP. I add for following bundles a CMakeLists.txt:

• Core
• Net
• Web
• ServiceListener sample

At the moment its only building some bundles. Launcher/Server part is missing yet.

[CLAassistant]

All committers have signed the CLA.

[lilianmoraru]

I did a fast skim through and besides a few nitpicks, this looks Really Good 😃

[obiltschnig]

Hi @Bjoe, could you please sign the CLA and then re-submit the pull request for the feature/cmake branch? We'll then merge to develop when its done.

Thanks!

[Bjoe]

@obiltschnig Ok, I sign the CLA.

[lilianmoraru]

A general point not specifically to be addressed by this issue but still relevant:

If the Poco code is not modified(compared to upstream), than switching to CMake, the copy of the code could be removed and let CMake make sure that the appropriate version is pulled in or updated.

Possible solutions:

1. There is the ExternalProject feature.
2. And my personal favorite is to add the dependency as a submodule and check at configure step for "submodule-name/.git", if it does not exist than I do: git submodule update --init(the builds of the submodule need to be out-of-source, so the update is seamless in case the reference was updated to a different version of the dependency). This makes sure that everything works, even if the user didn't clone with --recursive.

Both solutions with their advantages and disadvantages of course(ex: reliability vs perf)...

[Bjoe]

ExternalProject or git Submodule ... that's exactly what I think at the beginning, but unfortunately I did not come up with a correct solution.

From the build process perspective, Poco is a third party library for macchina, because Poco has its own cmake build. We should not mixed both project cmake builds togehther because they can influence each other. This means, ExternalProject is the right solution. The biggest disadvantage is, find_package(PocoXXX ) in macchina project will not proper work anymore! There are some solutions for this. I will figure out the solutions and try to create a test for you so that we can decide what we will use.

Btw. You can launch now macchina. After the build, execute, under Linux, bin/Linux/x86_64/macchina .... At the moment, all "binaries" are installed in the current build directory. If it is important that macchina is installed under the "server" folder, like the make based build, its also possible.

[Bjoe]

Hi @all. Here a new proposal/POC version of macchina.io. In the last year, I try to solve the "Poco third-party" problem. I tried with conan etc. but a few months ago I found Hunter. I try Hunter and I get some new ideas. It should be possible to build macchina/OSGi bundles without to "checkout" macchina project. Like a macchina SDK. First, I solved the problem with the poco third-party dependency. It is now very easy to update to newest poco version. Secound, I create a "macchina SDK" to build bundles indepentely. See here for example in my github repo: Bjoe/macchina-example-bundle To build the bundle:

$ git clone https://github.com/Bjoe/macchina-example-bundle.git
$ cmake -Hmacchina-example-bundle -Bbuild-macchina-bundle
$ cmake --build build-macchina-bundle

This will build a build-macchina-bundle/bundles/com.appinf.osp.samples.servicelistener_1.0.1.bndl bundle and it can be installed into macchina.io.

The first time, it take a while, because the third-party libraries (Poco and macchina) will be build with Hunter. After this libraries are build, it will not build again. You can change something in the bundle, and it will build only the bundle stuff, quickly.

[obiltschnig]

Thanks! I have also done some CMake work for OSP with a customer, so we'll probably have to merge the two approaches. Will look at it hopefully next week.