Add VxWorks to os in default settings.yml. (#10313)

[wackinger]

Closes #10313

Changelog: Feature: Add VxWorks to OSs in default settings.yml.
Docs: conan-io/docs#2355

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[CLAassistant]

All committers have signed the CLA.

[memsharded]

This is fine, adding VxWorks make sense.

There is still a couple of tests broken, because they list the available OSs in settings.yml, and that output changed now. Please see if you can fix them, otherwise we will help.

What would be very nice to have in the codebase is a full functional test that does some build of a package to VxWorks. Ideally with the most mainstream tooling (if building for VxWorks is commonly done with CMake, then using CMake). This test can be excluded from our CI with pytest.mark.tool_vxworks (check the conftest.py file in the test folder), but it should work locally when the vxworks tools are installed. This will serve as a documentation and also utility to debug and support users using VxWorks. Not necessary to add it in this PR, but if there is experience out there using Conan for VxWorks, it would be great to incorporate at least the basic knowledge in the codebase to be future-proof.

[memsharded]

I am going to approve this atm, and will comment on the docs PR.

I still would like to really test the things that are stated in the docs PR. It should be possible to write a unit-test that covers using os=VxWorks (and the necessary toolchain, via profiles, etc), that really builds and check the binaries, and that any user with the toolchain installed could execute. The conftest.py file can explain the configuration of the toolchain. We have struggled in the past to maintain insufficiently tested integrations, and having these tests would really help.

So if you please would consider adding this in the future, it would be fantastic, open an issue to discuss, and we will give guidelines.

[wackinger]

Great to hear. Thanks.
I'm still trying to find my way though the tests to find the right location to add a proper test.

[wackinger]

I'd love to provide sufficient tests, but am not familiar with the conan code base, yet. Could you perhaps give me a little hint on where to start to implement proper tests and what the proper preconditions would be? A pointer to an existing "exotic" toolchain/os test would be a great start. Thanks!

[memsharded]

Sure, I think the best would be something like this, testing clang in Windows: https://github.com/conan-io/conan/blob/develop/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py

• Very simple conanfile, building one executable
• The @pytest.mark.tool_clang(version="12") is what inhibits our CI to fail, as clang 12 not installed there. But configuring my conftest_user.py file, I can activate it
• As the self.run(cmd, env=["conanrunenv"]) will not be possible, it can be replaced with a simple check that the binary file exists (os.path.exists), or if there is some possibility to check the binary architecture with objdump or equivalent, that would be even better.
• No need to do several tests 1 single test for 1 configuration is ok.
• Depending on the build system, put in one place or another, under conans/test/functional/toolchains (dont know if vxworks uses always makefiles)

[memsharded]

It seems the test is doing just a normal native "clang" compilation, not cross-compiling to vxworks.

[memsharded]

In theory the binary created will not run in the current platform, is not executable, this shouldn't be possible.

[memsharded]

This self.run() should fail if the binary was actually cross-built for vxwork os. It should be replaced for some check of the binary.

[memsharded]

Is clang the compiler used to cross-compile to vxworks?

For cross compiling, it is typically necessary to provide a CC=full/path/to/cross/compiler env-var

[wackinger]

clang and ldarm are available in the path in my docker container.

[memsharded]

Ok, good, I was mostly wondering if clang is the compiler actually used to compile to vxworks, and no other compiler should go here.