CMake

[OgreTransporter]

It would be nice to have CMake support for macchina.io like the poco project.

[lilianmoraru]

The current build-system is maddening(not the kind of guy but it makes me want to yell out of rage), very hard to use.

[OgreTransporter]

I aggree to lilianmoraru! The current system is a pain!

[obiltschnig]

Contributions welcome ;-)

[Bjoe]

Hi. Add cmake support in macchina was also on my wish/todo list. I already started with this, but it is not yet usable. When I finished my Crypto X509 extension contribution (see pull request 1918 in poco) then I will come back to my cmake support in macchina :-). But maybe somebody already started with adding cmake support in macchina. Maybe I can help there?

[aleks-f]

@Bjoe see with @uilianries, he may be working on it

[uilianries]

Not yet, I'm working to finish #70. The recipe is able to build for amd64, but I need to finish armv7 support as well.

@Bjoe Did you post your cmake feature branch at github? Maybe I can fork it after to finish #70 and help you.

Regards.

[Bjoe]

@uilianries Sorry for the late answer. I get in trouble with this weird clang compiler bug (see 1950).

Did you post your cmake feature branch at github?

Yes I will do this. But let me cleanup a little bit. Again, it is not yet usable means... there are hardcoded path in there :-) for example. I should remove/fix this. But I will commit step by step.
Give me some days...

[uilianries]

@Bjoe Thanks for the report. I'm in trouble to finish #70 also, so I'll need some days too.

[Bjoe]

@uilianries I pushed a POC version. Many files are copied from Poco project.... should be cleanup. The interesting part are in macchina.io/platform/OSP. I added for some bundle a CMake file.

My idea or goal is, that I can create a bundle project without checking out macchina.io from the repo. There should be a "macchina.io dev" installation somewhere with the tools, libraries and headers that I need to build a bundle.

Thats why the bundle CMakeLists.txt looks like:

find_package(macchina.ioOSP)

set(BUNDLE_LIBRARY 
    .... source files ...
)

add_library(MyBundleLibrary SHARED ${BUNDLE_LIBRARY})
target_link_libraries(MyBundleLibrary  PocoOSP PocoNet PocoUtil PocoXML PocoFoundation)
target_include_directories(MyBundleLibrary PUBLIC include)

add_library(my.bundle SHARED ... source files ....)
target_link_libraries(my.bundle MyBundleLibrary)
 
create_bundle(TARGET my.bundle SPEC_FILE myBundle.bndlspec)

But the "infrastructure" of the cmake build system its not yet ready ... maybe this needs to be changed.

[uilianries]

@Bjoe I'll take a look ASAP. Thanks for the report! CMake support is a huge improvement in my opinion.

[lilianmoraru]

@Bjoe I think for an initial implementation it would be a considerable improvement to have the project build. The rest of the features can be added later, it might be overwhelming to try to implement everything from the beginning.

Btw, Instead of find_package(macchina.ioOSP) you probably want something more like the Qt5's Find(comes with the Qt installation): find_package(Qt5 COMPONENTS Core Widgets REQUIRED)

[OgreTransporter]

@Bjoe Thanks for your efford to create a CMake script! I've tried your branch:

CMake Error: File D:/poco/macchina.io/platform/cmake/cmake_uninstall.cmake.in does not exist.
CMake Error at platform/CMakeLists.txt:305 (configure_file):
configure_file Problem configuring file

@ALL I'm not sure it's a good idea to copy parts from Poco. For example, it tries to build NetSSL_Win even though it does not exist. Isn't it useful to either define Poco as a dependency or to integrate Poco completely as a Git submodule?

[aleks-f]

Isn't it useful to either define Poco as a dependency or to integrate Poco completely as a Git submodule?

it is, but there are sticky points, like OSP and CodeGeneration. There's an issue for that: #15

[Bjoe]

@uilianries Don't be stressed. I have also few tickets open that I will finish and close before I get deeper into cmake support for machhina.

CMake support is a huge improvement in my opinion.

Yep 👍

I think for an initial implementation it would be a considerable improvement to have the project build. The rest of the features can be added later, it might be overwhelming to try to implement everything from the beginning.

@lilianmoraru Ok, that's also my idea. That's why I "copy/paste" most from poco project and create a pull request to start a discussion which direction we will go. In the OSP I added only my proposal :-).

you probably want something more like the Qt5's Find find_package(Qt5 COMPONENTS Core Widgets REQUIRED)

Yes, boost does this also. I also thinking about this. I use here the poco project approach. Unfortunately it is not possible to do this there.

I've tried your branch...

@OgreTransporter Well it is a POC (proof of concept) and it is not really usable.

I'm not sure it's a good idea to copy parts from Poco.

@OgreTransporter I'm also not a big fan of copy paste and this files(GLOB *.cpp) approach has side effects. But macchina is based on poco project and we have here poco project developer they have knowledge about the cmake stuff from there. So for me it was logical to use first the stuff from there and see if it is possible to reuse it. Now we can decide if we will use it.

For example, it tries to build NetSSL_Win even though it does not exist.

@OgreTransporter This lines 52-60 in CMakeList.txt is only a "Hack". Should be cleanup when we decide if we will use the cmake stuff from pocoproject or not.

Move platform into separate project.

👍

I think, what learn from the POC and what I understand from the discussion, we need something new for the OSP part. But I also think we should use the cmake stuff from pocoproject for the poco parts. Especially when we seperate the project and add poco project as git submodule for example.

But maybe it is a good idea to get it done as @lilianmoraru said, and build macchina first like the make based build system. After that we can refactor.