FMU-proxy orchestration support

[markaren]

FMU-proxy support for PR #233

[markaren]

I've updated the PR to use the new iteration. I added some ad-hoc changes to the original code. Should be fixed upstream and merged back.
Cavecat with fmu-proxy file support. Files MUST be relative.

[markaren]

I guess we could modify orchestration.cpp with something like:

#if __has_include(<cse/fmuproxy/fmuproxy_uri_sub_resolver.hpp>)
#DEFINE HAS_FMUPROXY
#include <cse/fmuproxy/fmuproxy_uri_sub_resolver.hpp>
#endif

....

std::shared_ptr<model_uri_resolver> default_model_uri_resolver()
{
    auto resolver = std::make_shared<model_uri_resolver>();
    resolver->add_sub_resolver(std::make_shared<file_uri_sub_resolver>());
#ifdef HAS_FMUPROXY
  resolver->add_sub_resolver(std::make_shared<fmuproxy_uri_sub_resolver>());
#endif
    return resolver;
}

?

[ljamt]

We concluded to keep the fmu-proxy flag last meeting, so we need something like that yes. We can discuss this tomorrow.

[markaren]

I'm travelling btw, but I'll be available at slack if there should be any discussion afterwards.

[ljamt]

We are getting close to merge this PR. How shall we do that? This PR is requesting to merge into feature/165-generic-fmu-interface

BTW, I think your proposal for adding the sub_resolver is good @markaren

[markaren]

I would suggest to merge #233 first, then change the target of this to master.

[kyllingstad]

Looks good now!

We'll need to figure out what to do about running the tests, but that was a pre-existing problem that is not related to this PR.

[kyllingstad]

I would suggest to merge #233 first, then change the target of this to master.

I agree, this is the cleanest way to do it.

[ljamt]

Linux build agent is up and running again, and Build on Linux with Conan & FMU-proxy support build currently fails.

[kyllingstad]

BTW, I think your proposal for adding the sub_resolver is good @markaren

Same here. It could be added in the final PR (to master).

[markaren]

The error is

/home/****/****_slave/workspace/5-generic-fmu-interface-fmuproxy/cse-core/src/cpp/fmuproxy/remote_fmu.cpp:7:0: error: ignoring #pragma warning  [-Werror=unknown-pragmas]

 #pragma warning(push)

 
/home/****/****_slave/workspace/5-generic-fmu-interface-fmuproxy/cse-core/src/cpp/fmuproxy/remote_fmu.cpp:8:0: error: ignoring #pragma warning  [-Werror=unknown-pragmas]

 #pragma warning(disable : 4245)


/home/****/****_slave/workspace/5-generic-fmu-interface-fmuproxy/cse-core/src/cpp/fmuproxy/remote_fmu.cpp:12:0: error: ignoring #pragma warning  [-Werror=unknown-pragmas]

 #pragma warning(pop)

How to best resolve @kyllingstad ?

Add a #ifdef __WIN32 perhaps ?

[markaren]

Thrift does:

#ifdef _MSC_VER
  #pragma warning( push )
  #pragma warning (disable : 4250 ) //inheriting methods via dominance 
#endif

which is better than using #ifdef _WIN32 I guess

[markaren]

There is another linux error. Will fix when I get back to a linux machine tomorrow.

[kyllingstad]

which is better than using #ifdef _WIN32 I guess

Yes, #pragma warning is MSVC specific.

There is another linux error.

Only the #pragma directives should be enclosed in #ifdef _MSC_VER, not the #include directives.

[ljamt]

Jenkins is happy 🎉

[ljamt]

Then it's only the final modification of orchestration.cpp to include the sub resolver left.

[markaren]

#if __has_include(<cse/fmuproxy/fmuproxy_uri_sub_resolver.hpp>) seems to be true with FMUPROXY=OFF ..

[markaren]

This is caused by

target_include_directories(csecorecpp
    PUBLIC
        "$<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>"
    PRIVATE
        "${CMAKE_CURRENT_SOURCE_DIR}"
)

no?

Should we rather specify a add_definition("WITH_FMUPROXY") in the CMake file? @kyllingstad

[kyllingstad]

Great!