-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cmake] Use GNU install dirs variables instead of hardcoded value #1892
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the PR!
The only concern I have, that by using the values in the ecal or lang/csharp subfolders, we will no longer be able to build these components on their own.
We could introduce eCAL_core_xxx
directories, or use the CMAKE_INSTALL_...
variables directly there.
Or, as I think that specifying the install directories is no longer required in CMake (I think they were before CMake 3.15, or so), maybe it could be deleted altogether.
endif() | ||
set(INSTALL_CMAKE_DIR ${DEF_INSTALL_CMAKE_DIR} CACHE PATH | ||
"Installation directory for CMake files") | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit strange that we still have those when we do provide all these eCAL_install
directories.
Not sure what you mean w.r.t the ecal subfolder as eCAL core already uses the values (eg: ecal/ecal/core/src/ecal_defs.h.in Line 37 in 3b22b6e
The csharp and python subfolders can't currently be built independently as they lack the requisite
That's pretty accurate. For "For regular executables, static libraries and shared libraries, the DESTINATION argument is not required. For |
Description
Removes hardcoded install destinations that aren't derived from the appropriate
CMAKE_INSTALL_<DIR>
, without this the special caseCMAKE_INSTALL_PREFIX
of/
behaves incorrectly, with files split between (for example)/usr/include
and/include
Replaces the following uses with their
eCAL_install_<DIR>
equivalents:INSTALL_LIB_DIR
INSTALL_BIN_DIR
INSTALL_INCLUDE_DIR
INSTALL_CMAKE_DIR
(was unused)Moved the
asioTargets.cmake
fromlib/CMake
tolib/cmake
consistent with elsewhere.Gets hdf5 submodule to use the GNU install dirs.
This should only really make any difference at all when
CMAKE_INSTALL_PREFIX
is exactly/
; which admittedly is rare and unusual. Beyond that, it does mean all the install paths are now user controllable.Related issues
Cherry-pick to