You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When integrating Interop as a dependency into another CMake-driven C++ project, it is difficult to govern the parts of Interop that are being installed/deployed together with the parent project.
The current approach I'm following consists of pulling in this Git repo as a submodule into $MY_PROJECT/external/interop and including it via add_subdirectory(interop) from within $MY_PROJECT/external/CMakeLists.txt. Thereby, I pre-set several Interop CMake options via set(... ON|OFF CACHE BOOL "" FORCE), e.g. set(ENABLE_CSHARP OFF CACHE BOOL "" FORCE) before the add_subdirectry(...) statement.
Issue 1
For my deployment scenario (Unix only) I'm preferring shared libraries. However, I don't see any possibility to select only one of libinterop_fpic_lib.so or libinterop_lib.so of ending up in $PREFIX/lib64 after a make install of my project.
Suggestion 1
add an option to choose between the position independent and the position dependent variants of libinterop while defaulting to the current behavior:
option(ENABLE_SHARED_FPIC "build (and install) a position-independent variant of the share library"ON)
option(ENABLE_SHARED_FPIC_ONLY "only build (and install) the position-independent variant of the shared library"OFF)
Resulting in the following combination matrix:
ENABLE_SHARED_FPIC / ENABLE_SHARED_FPIC_ONLY
libinterop_fpic_lib.so
libinterop_lib.so
ON / OFF
X
X
ON / ON
X
-
OFF / any
-
X
Issue 2
In addition, the LIBRARY DESTINATION and ARCHIVE DESTINATION paths are hard coded to lib64. It would be great utilizing GNUInstallDirs's LIBDIR to get a consistent path across a CMake (super-)project on the same system.
Suggestion 2
Use GNUInstallDirs's LIBDIR/BINDIR when defining the destination of LIBRARY and ARCHIVE install targets:
Thank you for the suggestions. We just started to refactor the build scripts, so we can incorporate these in the next release.
I don't have a workaround for Issue 1: building both libraries. In the future, we won't build a position independent library when building shared libraries.
For Issue 2, you could use ExternalProject_Add and point it to the git repo. You can then override the installation behavior in a number of ways to achieve what you want above. For example you could use:
When integrating Interop as a dependency into another CMake-driven C++ project, it is difficult to govern the parts of Interop that are being installed/deployed together with the parent project.
The current approach I'm following consists of pulling in this Git repo as a submodule into
$MY_PROJECT/external/interop
and including it viaadd_subdirectory(interop)
from within$MY_PROJECT/external/CMakeLists.txt
. Thereby, I pre-set several Interop CMake options viaset(... ON|OFF CACHE BOOL "" FORCE)
, e.g.set(ENABLE_CSHARP OFF CACHE BOOL "" FORCE)
before theadd_subdirectry(...)
statement.Issue 1
For my deployment scenario (Unix only) I'm preferring shared libraries. However, I don't see any possibility to select only one of
libinterop_fpic_lib.so
orlibinterop_lib.so
of ending up in$PREFIX/lib64
after amake install
of my project.Suggestion 1
add an option to choose between the position independent and the position dependent variants of libinterop while defaulting to the current behavior:
Resulting in the following combination matrix:
Issue 2
In addition, the
LIBRARY DESTINATION
andARCHIVE DESTINATION
paths are hard coded tolib64
. It would be great utilizing GNUInstallDirs'sLIBDIR
to get a consistent path across a CMake (super-)project on the same system.Suggestion 2
Use GNUInstallDirs's
LIBDIR
/BINDIR
when defining the destination ofLIBRARY
andARCHIVE
install targets:The text was updated successfully, but these errors were encountered: