search

open-simulation-platform / cosim-cli

Command-line interface for libcosim
https://open-simulation-platform.github.io/cosim
Mozilla Public License 2.0
10 stars 4 forks source link

Cosim-cli 0 10 1 release #104

Closed restenb closed 1 year ago

restenb commented 1 year ago

Preparing for v0.10.0 release of cli as well.

@markaren @kyllingstad Thrift-related build error propagated here as well. Fixed by adding CMAKE_MODULE_PATH and CMAKE_PREFIX_PATH but there are still problems building & linking the executable.

Notably, there's a lot of errors like error C2039: 'optional': is not a member of 'std', and various other errors about C++17. Maybe stdc++ needs to be linked?

I was able to build cosim.exe by adding target_compile_features(cosim PRIVATE "cxx_std_17"), but then the required DLLs like boost::program_options are not linked.

markaren commented 1 year ago

set(CMAKE_CXX_STANDARD 17) does the trick. Or target_compile_features(cosim PRIVATE "cxx_std_17").

However, this project is setup in a way that you need to copy dlls to run the executables using my normal worklow. I also got a weird runtime error when invoking cosim.exe: 

error: internal: vector too long

Process finished with exit code 70
kyllingstad commented 1 year ago

I think this happens because the code no longer gets compiled as C++17, and I believe the reason is the addition of the cmake_find_package generator in conanfile.txt.

Here‘s what‘s supposed to happen:

  1. libcosim has C++17 as a public compilation feature, meaning that libcosim itself gets compiled as C++17, and this is also supposed to be inherited by client code.
  2. This inheritance happens by means of libcosim's package configuration file[^1], to which the information about targets and their properies gets exported.
  3. On the cosim-cli side, this file is supposed to be picked up by find_package(libcosim).

My hunch is that find_package(libcosim) now picks up the Findlibcosim.cmake script that is generated by cmake_find_package rather than the libcosim-config.cmake script that gets installed alongside libcosim.

I haven't picked up what the motivation was for using cmake_find_package, but assuming that we need it, I still think this behaviour can be overridden. I'll suggest a change of the appropriate code line.

[^1]: The package configuration file is a CMake thing; it has nothing to do with Conan packages. You can find the instructions that generate it in libcosim's main CMakeLists.txt.

markaren commented 1 year ago

I've made a PR for proxyfmu that will fix the current issues. Will require a patch release of libcosim. Fixing it in the consumers is doable (like setting C++17 standard) in this PR, but it's patchwork from a deeper issue.

https://github.com/open-simulation-platform/proxy-fmu/pull/83

restenb commented 1 year ago

Updated again following 0.10.1 libcosim release & we're in the green again.

Tested & works locally on windows. Awaiting courtesy approval of changes before release.