Poco-Source

[OgreTransporter]

I'm wondering that there is a copy of the poco libraries in this project. I think it's better to include poco as a git sub module, because in this case bugfixes from poco are also available for macchina.io. The mirai bot net used insecure IoT devices so it's neccesary to update macchina.io as fast as possible after a bugfix has been submitted to poco.

[uilianries]

Hi!
I'm using conan.io to solve my project dependencies, including Poco.
Machinna.io could use Conan to include Poco as dependency, instead copy whole project.

[OgreTransporter]

Hi!

Nice idea, but conan.io is not necessary, because you could use poco as a git sub module. This includes the poco source code on git clone/fetch/pull.

[aleks-f]

git submodule is proper solution; however, it requires buildsystem changes because poco libraries are now spread directly under platform directory. OSP should also be moved into separate repository and included as submodule, see #15

I'm thinking probably the cleanest solution would be POCO and OSP in separate submodules, the rest either directly under platform or moved to the submodules if it makes sense.

if anyone wants to tackle this, go for it, see also #53

conan is a separate concern from this

[obiltschnig]

Before anyone starts doing some work regarding this - please coordinate with me first.

[OgreTransporter]

I agree, changing the build system to CMake (#53) is a necessary requirement. With CMake it is also easy to integrate the build scripts from submodules into the build system of the main project. E. g. this means that the CMake script "platform" can build Poco and OSP as submodules. It is not necessary to carry (possibly outdated) dependencies with you.

But where to start? First switch to CMake and then outsource OSP? Or outsource OSP first and then switch to CMake?

[obiltschnig]

Switch to (add support for) CMake to macchina.io first. This is already planned for July for a customer project.