Support for conan package manager

[memsharded]

Hi!
I have done preliminary support for Robot in conan.io package manager:

https://github.com/memsharded/conan-robot, https://www.conan.io/source/Robot/2.0/memsharded/testing

I am using fork in this PR #23, because it is more convenient having a CMakeLists.txt.

So far, I have tested in VS12, and 14, both shared and static libraries. I usually setup CI (travis, appveyor) for packages. It is possible to manage the package adding the conanfile.py to the main repository instead of an external one, just in case you are interested, but not necessary at all.

Please tell me whether you could be interested in this, want more info, have questions, want help setting up CI... or just close the issue it if not interested, not a problem, thanks anyway for creating and sharing this great project.

[dkrutsko]

Hi, I've actually never heard of Conan before but I'm all for making this library as accessible as possible. With regards to CMakeLists.txt, Sqeaky is leading the charge with the implementation through PR #23 and issue #17, so it may be used freely.

At one point I did want to set up a CI but the problem was that testing this library is not easy. There's a lot of manual work which needs to be done. However types and timer are fully automated and if they pass, then there's a good chance everything else will pass as well. If you have experience setting up CI's and it's something you'd like to do then sure!

I'll have to look into Conan a bit more, in the meantime it looks like a great idea. The release cycle won't be super quick so you may be stuck with using an external conanfile.py or a fork of the project but do a PR into the dev branch and it'll be integrated with the next release. Thanks again for your support and keep up the fantastic work.

[memsharded]

Great, thank you :). Regarding the testing, I know, I have been running some of them, and they involve a lot of manual testing. But in any case, just setting CI and ensuring that everything builds in different platforms and compilers and some basic tests pass, is already very useful. I have done this several times, shouldn't be difficult once the CMakeLists.txt is in develop, I will keep an eye on this, thanks!

[Sqeaky]

What are the build targets for Conan? I am not familiar with it either.

Depending on what you need, the CMakeLists.txt I added might already be useful. I am still working on it in a fork though.

[memsharded]

Yes, yes, I am already using your fork @Sqeaky, really useful, worked great so far.

I am just running cmake --build . --config Release which I think builds the ALL target. I haven't check the internals of your CMakeLists.txt if you use targets to separate tests, etc, I could probably run just the library target. Not critical though. The full package recipe if you want to have a look can be found in: https://github.com/memsharded/conan-robot/blob/master/conanfile.py. Also preliminary, only tested in Win, support for Linux and Mac should be very simple. Also, I am using now the HEAD at time of packaging which is not correct, I should change it to the actual release tag.

I watch this repo, when your branch gets merged, I will update the recipe too. Then, if you are interested, I could help setting up CI for robot packages. The typical builds are Win (MSVC 10 to 14) in several 32/64 Debug/Release Static/Shared configurations, Linux gcc from 4.8 to 5.3 (5.1 skipped) in Debug/Release Static/Shared (32 bits are problematic in 64bits linux, I usually skip them), then OSX , similary. For example, for ZMQ, I am creating 86 different configurations, check: https://conan.io/source/ZMQ/4.1.1/memsharded/testing.

[Sqeaky]

I do not think my current repo works on Mac OS X. I copied build settings from the initial makefile, and simply did not copy and for Mac OS X, so if it works, it works by happenstance.

I am open to helping with CI, but I must do one thing at a time I will commit docs and the last few updates I have sitting on my machine.

[memsharded]

No, sorry, I have just tested in Win MSVC. I still have to check OSX and Linux, typically is necessary to add a couple of lines. But, I agree, one thing at a time. I think that the best would be to wait until CMake support is merged into the main repository, then I will check and add support for OSX and Linux. Then, I dont mind to do a preliminary setup of CI, as initial proposal. Would this roadmap be fine?

[Sqeaky]

@memsharded I found and fixed a bug dealing with dynamic linking. See #30.

It is obscure, but seeing as you are building a package manager many people might be using your packages and some in a way similar to what I did.

[memsharded]

Thanks for telling. Yes paths to shared libs is a real pain, we have already had some issues and we'll sure have more. I will take this into account, thank you!