cmake: Modernize exported CMake config files

[neverpanic]

The CMake configuration files exported by CommonAPI-SomeIP require users to add the ${COMMONAPI_SOMEIP_INCLUDE_DIRS} variable to their project's include directories. This was done to support building against a build tree of CommonAPI-SomeIP by generating two different CommonAPI-SomeIPConfig.cmake files that defined this variable with different values.

This is now no longer necessary since CMake supports the $<BUILD_INTERFACE> and $<INSTALL_INTERFACE> generator expressions which can be used to make the same distinction with only a single CommonAPI-SomeIPConfig.cmake file.

This also allows users of CommonAPI-SomeIP to get the required include directories into their build by using

target_link_libraries(${target} CommonAPI-SomeIP)

since the exported CommonAPI-SomeIP CMake target now has the required include directories set as a property. This is much more idiomatic for users of CMake and is thus preferred.

Additionally, the exported target required users to manually find a copy of vSomeIP and link against vSomeIP as well as against CommonAPI-SomeIP rather than automatically locating the vSomeIP dependency. Modify the target to also do this step automatically so that users of CommonAPI-SomeIP only need to care about the CommonAPI-SomeIP target.

This enables downstream projects that build CommonAPI interface libraries to no longer care about what the CommonAPI-SomeIP include directories are, which simplifies writing CMake config files for them.

I've locally compiled vSomeIP, CommonAPI, CommonAPI-SomeIP and a test project using CommonAPI-SomeIP to test this.

[gunnarx]

Correct spelling is "publicly" FYI. You still have time to change it ;-)

[neverpanic]

Will do, thanks for the hint.

[neverpanic]

Typo now fixed.

[derived-coder]

Why is this not merged? @neverpanic Can you also provide a fix for: https://github.com/GENIVI/vsomeip ?

[neverpanic]

@derived-coder I don't know. Internally, all ECU projects I'm aware of are shipping this patch for a couple of months now, so it's certainly well-tested by now.

There is a corresponding PR for vsomeip, btw: https://github.com/GENIVI/vsomeip/pull/41. I guess Lutz hasn't gotten around to publishing version 3.x yet.

[derived-coder]

@neverpanic Thanks. I guess all genivi projects don't use modern cmake atm. Here I saw there is no PR open from you: https://github.com/GENIVI/dlt-daemon Or do you have also one?

[neverpanic]

@derived-coder I didn't make one for dlt, since it didn't have the problem of breaking dependent CMake configuration files similar to what the CAPI runtimes did (we have tooling to turn fidl and fdepl files into libraries rather than compiling them directly into your application, but in order to write CMake configurations for these libraries, the changes in the PRs I opened were required for proper cross-compiling; the same problem didn't apply for DLT).

Feel free to open a corresponding PR for DLT, though. Let me know if you do, I might be able to poke people to get that merged, or help with testing.