Add install and uninstall targets

[traversaro]

Fix https://github.com/SFI-Mechatronics/FMI4cpp/issues/8 .
I tried to follow the latest CMake guidelines, and I added links to the relevant documentation in the comments. @markaren let me know if you prefer that I expand those.

With this patch, you can install a given directory by specifying the CMAKE_INSTALL_PREFIX CMake variable. Once you installed the library, you can find it in a downstream project by adding the CMAKE_INSTALL_PREFIX directory to the CMAKE_PREFIX_PATH cmake or environmental variables.
In the downstream project the library can be used as in:

find_package(FMICPP REQUIRED)

target_link_libraries(<target> PUBLIC FMICPP:fmicpp)

Additional work is necessary to make sure that the CMake package is relocatable, but I though it was better to first get this initial support in. Relocatable packages are convenient for inclusion in vcpkg (see microsoft/vcpkg#1027 and microsoft/vcpkg#77).

Regarding the naming, the name of the package is connected to the name of the project in CMake. is FMICPP ok? Is the library supposed to be called FMI4cpp, FMICPP or fmicpp?

[markaren]

Thanks! I will try to have a look at this evening.

[traversaro]

Let me know if you have any additional question: CMake package export has always been tricky, but luckily the quality of CMake documentation and related material available online has been stedly improving during the latest years.

[traversaro]

An additional thing that you may want to evaluate at this is there are any headers in include that you do not want to be part of the public API of the library.

[markaren]

Is the library supposed to be called FMI4cpp, FMICPP or fmicpp

Good question. The project name is FMI4cpp, but fmi4cpp is a terrible namespace, which is why the namespace currently used is fmicpp. That's also why the CMake project is named fmicpp and not fmi4cpp. Probably FMICPP is ok for the CMake project name, although the actual project name is FMI4cpp.

[markaren]

An additional thing that you may want to evaluate at this is there are any headers in include that you do not want to be part of the public API of the library.

Yeah, there is that. Have not thought much about it really. We'll just have to see with time I guess.

[traversaro]

Yes, iterating a bit make sense. Once the interface have been stable for a while, it could make sense to release a 1.0 version (that is also what Semantic Versioning suggests: https://semver.org/)

[traversaro]

Good question. The project name is FMI4cpp, but fmi4cpp is a terrible namespace, which is why the namespace currently used is fmicpp. That's also why the CMake project is named fmicpp and not fmi4cpp. Probably FMICPP is ok for the CMake project name, although the actual project name is FMI4cpp.

As you are interested in vcpkg integration, consider that vcpkg requires all its cmake configuration files to be installed in a directory called <prefix>/share/<vcpkg_port_name>, and so if the <vcpkg_port_name> is different from the CMake package name the CMake integration could fail.

[markaren]

As you are interested in vcpkg integration, consider that vcpkg requires all its cmake configuration files to be installed in a directory called <prefix>/share/<vcpkg_port_name>, and so if the <vcpkg_port_name> is different from the CMake package name the CMake integration could fail.

Does having the project name (GitHub) be FMI4cpp, the CMake project (and vcpkg port) be named fmi4cpp and the namespace be fmicpp sound ok?

[traversaro]

Does having the project name (GitHub) be FMI4cpp, the CMake project (and vcpkg port) be named fmi4cpp and the namespace be fmicpp sound ok?

This should work fine, at least w.r.t. to the CMake/vcpkg integration.

[markaren]

Took the liberty to change the base branch and merge with dev