WIP: Target exporting with CMake

undisputed-seraphim commented 1 year ago

This merge request aims to implement proper target exporting and importing with CMake.

I need to make these changes because certain embedded platform build systems expect myproject-targets.cmake files to be present in order to facilitate dependency resolution. Existing dependency layers that are bundled with the build system also expect other dependencies to be reasonably well-behaved (does not force-set CMake variables that leak across projects).

High-level overview of changes:

md5 moved into its own project - This is because OpenRAVE uses only those symbols and it is unnecessary to link against the whole cpp-gen-md5 binary just to get basic md5 symbols. This has to be changed because otherwise cpp-gen-md5 also has to be exported and installed together with libopenrave.
Added EXPORT to most install() commands.
Use find_package(Python2) to set Python-related directories, and the now-deprecated find_package(PythonLibs 2) code is removed.
Rewrote openrave-config.cmake.in to fit modern standards.
openrave-config-version.cmake deleted - It is now automatically generated by CMake.
myrelpath.py deleted - It is used solely to determine the prefix path of the installation directory of python modules, but CMake has a built-in function for this now.
Adjusted the linking visibility of some libraries so they can be comfortably exported (CMake throws an error otherwise)
Use version agnostic FindPython, and converted the linking syntax from old CMake 2.x syntax to the CMake 3.x target-based syntax. (Note that support for <= CMake 2.8.12 will be dropped in a future release.)

There is also a compatibility shim so that existing libraries that use deprecated behaviours continue to work, but ideally we should fix downstream libraries and them remove this shim.

After this change, any project that wishes to link against OpenRAVE in CMake do not need any to do any voodoo; simply find_package(OpenRAVE REQUIRED) and then target_link_libraries(myproject PUBLIC OpenRAVE::OpenRAVE).

cielavenir commented 1 year ago

oh please check if this change is still compatible with Python3 flavor

undisputed-seraphim commented 1 year ago

oh please check if this change is still compatible with Python3 flavor

The change is purely CMake only, to target Python3 we just change all find_package(Python2 ...) to find_package(Python3 ...)

cielavenir commented 1 year ago

to target Python3 we just change all find_package(Python2 ...) to find_package(Python3 ...)

we will need to patch a lot.

Also, Currently the behavior can be changed by installing python-is-python2 or python-is-python3 without changing CMakeLists, but we will lose that capability.

undisputed-seraphim commented 1 year ago

to target Python3 we just change all find_package(Python2 ...) to find_package(Python3 ...)

we will need to patch a lot.

Also, Currently the behavior can be changed by installing python-is-python2 or python-is-python3 without changing CMakeLists, but we will lose that capability.

We can use FindPython , which will define target names that are version agnostic. i.e.,

find_package(Python 2.7 REQUIRED COMPONENTS Interpreter Development NumPy)
...
target_link_libraries(my_library PUBLIC Python::Module Python::NumPy)

That way, we only need to change 2.7 to 3.x without having to change anything else.

Does that work for you?

cielavenir commented 1 year ago

Sure that should be ok

undisputed-seraphim commented 1 year ago

Closing this due to developments on another branch involving CMake.

rdiankov / openrave

WIP: Target exporting with CMake #1184