Test environment (using `vcpkg`)

[aarlt]

Hey! I created a very simple test environment for autobahn-cpp. I thought it will be quite useful, in case of future development. Initially I realised, if we change even simple things - e.g. replacing openssl with botan (right now only the hmac function is used from openssl - it would be very important to know whether such change did not introduce strange behaviour.

For this I rewrote the build system a bit - it will now use vcpkg as the "package manager". With that external dependencies like openssl, botan, boost, msgpack or websocketpp can be easily added to the cmake build-system. Furthermore it is more easy to build them for different platforms.

I configured catch2 to be used as the test framework.

Additionally to the examples - that will also be compiled for the different platforms - tests can be defined in the test/ directory. Here every test can be defined within its subdirectory. Each test will interact with a wamp router. I decided to use crossbar for this - because it is very easy to integrate. That means that for each test the corresponding crossbar configuration will be used to start the crossbar router (it will use the crossbar docker images). The different tests are also defined in cmake, that allows the usage of ctest. If you already have docker running, a simple make, make test will run the test cases and automatically starting the needed docker that gets configured with the corresponding crossbar configuration.

I also defined a GitHub workflow, that will build everything for linux, macOS & windows. Sadly I did not find any way how to execute the docker on windows. Thats why right now only the tests gets only executed in linux & macOS.

Let me know your opinion about this PR. I hope that the GitHub workflow will just work here - lets see :D

[aarlt]

Ah sorry! I totally forgot to explicitly write down how to build everything. Especially because the magic of how vcpkg is being setup is not explicitly shown in the workflows.

However, if there is no vcpkg installed on the system, run the following commands:

# checkout
git clone git@github.com:aarlt/autobahn-cpp.git
cd autobahn-cpp
git checkout test-environment

# initialise vcpkg
git submodule update --init --recursive
vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=$(pwd)/vcpkg

# build
mkdir build
cd build
cmake ..
make

# test (if docker daemon is running)
make test

If vcpkg is installed, just make sure that the environment variable VCPKG_ROOT points to its location.

[oberstet]

@aarlt sorry for delayed response, this is super cool!!

[oberstet]

Sadly I did not find any way how to execute the docker on windows.

vcpkg is by Microsoft - does MS also provide official GitHub actions for vcpkg for testing on Windows? Is https://github.com/marketplace/actions/run-vcpkg providing "official" GH actions?

for conan, this is available, eg here is a last successful run:

https://github.com/crossbario/autobahn-cpp/runs/4970906148?check_suite_focus=true#step:1:3

Let me know your opinion about this PR.

so one decision taken in this PR, basically the one "decision" that we should take consciously is

switch from Conan to vcpkg as package manager for all platforms, while keeping cmake as build system for all platforms

Is that true?

vcpkg is made by Microsoft, and is OSS (MIT):

"C/C++ dependency manager from Microsoft - For all platforms, buildsystems, and workflows" https://vcpkg.io/en/index.html https://github.com/microsoft/vcpkg/blob/master/LICENSE.txt

Conan seems like a widely used and established package manager https://conan.io/, while vcpkg is new?

Sorry for asking such dumb questions .. I never used vcpkg, and I'm not that deep into C++ ecosystem and community trends these days, so ...

---

basically my question is:

• stuff (including packaging) works for me using Conan, which is a standard OSS tool
• why would I want to risk using any Microsoft stuff?
• why would I risk breaking stuff on Linux, which is what I care about?

the only answer I can find for me to above:

• because I like Windows and strive for pointless work

which isn't true;)

sorry for asking in such a provocative way, I guess I just cannot forget how the world suffered in the 90s under MS dictatorship.

also, I'm not in principle against using MS tools. including on Linux.

however, I like to avoid a situation where I have to fuzz around with a shitty MS tool - on Linux. because I needlessly bound myself to a MS shit universe. It's not even 10yrs that I escaped the evil empire ... zero motivation to go back.

[oberstet]

so in my mind, it boils down to a decision we need to take:

1. [ ] leave stuff like it is (conan+cmake) and remove Windows CI / official support announcement
2. [ ] move everything on all platforms to vcpkg+cmake, have Windows CI and official support announcement (this PR)

I'm fine with 1., as I don't care about Windows and won't waste any significant time on it.

I'd be fine with 2. in principle but have worries ^ ...

[aarlt]

vcpkg is by Microsoft - does MS also provide official GitHub actions for vcpkg for testing on Windows? Is https://github.com/marketplace/actions/run-vcpkg providing "official" GH actions?

We could just download vcpkg within this workflows by our self and configure it (basically just like shown above). So we would not need any external GitHub action.

for conan, this is available, eg here is a last successful run:

https://github.com/crossbario/autobahn-cpp/runs/4970906148?check_suite_focus=true#step:1:3

Yeah, Conan would be an alternative. Actually this was the first time that I'm using vcpkg - I just wanted to try it, because I was curious. Everything just worked. I was really impressed. The funny thing is that I also did not really realise that you where using Conan here. I was too much focused on the CMake files. We could also just switch to Conan. However, from my point of view vcpkg seem to be a good option.

so one decision taken in this PR, basically the one "decision" that we should take consciously is

switch from Conan to vcpkg as package manager for all platforms, while keeping cmake as build system for all platforms

Is that true?

Yeah to be able to really build external libraries (e.g. Boost, OpenSSL & Botan) where someone is not dependent on the system libraries, we need a package manager like Conan or vcpkg, where vcpkg allows a very easy integration in CMake, but I guess Conan also supports it. However, because of the easy integration of vcpkg I even don't really see that vcpkg is something different, it is just a part of CMake build system. I know that the decision Conan vs. vcpkg is not easy.

vcpkg is made by Microsoft, and is OSS (MIT):

"C/C++ dependency manager from Microsoft - For all platforms, buildsystems, and workflows" https://vcpkg.io/en/index.html https://github.com/microsoft/vcpkg/blob/master/LICENSE.txt

Conan seems like a widely used and established package manager https://conan.io/, while vcpkg is new?

I think vcpkg Is not really new (it was first released 2016), its just another package manager for c++. I guess we could also just use Conan.

Sorry for asking such dumb questions .. I never used vcpkg, and I'm not that deep into C++ ecosystem and community trends these days, so ...

No problem. I totally understand your point.

basically my question is:

• stuff (including packaging) works for me using Conan, which is a standard OSS tool

Yes, we could do the same with Conan. But vcpkg is also a standard OSS tool.

• why would I want to risk using any Microsoft stuff?

I would not say that we don't have a risk here by using Microsoft stuff. Or is there an issue with the MIT license?

• why would I risk breaking stuff on Linux, which is what I care about?

We will not break anything under Linux by using vcpkg. But if you prefer Conan, I could look into how to do those things with Conan.

the only answer I can find for me to above:

• because I like Windows and strive for pointless work

which isn't true;)

sorry for asking in such a provocative way, I guess I just cannot forget how the world suffered in the 90s under MS dictatorship.

I totally get your point. I was also really surprised how nicely vcpkg could be integrated and how nicely it just worked. I think its quite good, robust software.

also, I'm not in principle against using MS tools. including on Linux.

however, I like to avoid a situation where I have to fuzz around with a shitty MS tool - on Linux. because I needlessly bound myself to a MS shit universe. It's not even 10yrs that I escaped the evil empire ... zero motivation to go back.

I really get your point. If you prefer we could use Conan, I guess I don't have a problem with this. But vcpkg seem to be great and is really a good alternative to Conan. Microsoft did not write vcpkg to be used only in windows, this tool also runs great under macOS & Linux (and possibly others). I think in general, just because vcpkg is from Microsoft, it cannot be compared with mistakes Microsoft did in the past with their operating system & company politics.

However, I guess the main decision is now vcpkg vs. Conan. For now I would prefer vcpkg, because I don't know Conan that good. But that's a good motivation to really look into Conan. I think I will fork this PR and replace vcpkg with Conan then we could just compare and then decide.

Ah and also, because you're using Conan for packing, I did not add any packaging support yet to the CMake. At least I did not test anything related to packaging. I guess everything would get packed now, not just autobahn/. But I need to check.

[aarlt]

so in my mind, it boils down to a decision we need to take:

1. [ ] leave stuff like it is (conan+cmake) and remove Windows CI / official support announcement
2. [ ] move everything on all platforms to vcpkg+cmake, have Windows CI and official support announcement (this PR)

I'm fine with 1., as I don't care about Windows and won't waste any significant time on it.

I'd be fine with 2. in principle but have worries ^ ...

I understand your points. Let me create a PR that is basically this one but using Conan. And then let's just see how it compares.