access to PRIVATE, PUBLIC keywords on TARGET_LINK_LIBRARIES

[nschloe]

After the CMake requirement will have been increased to 2.8.11, I would like to have access to the LINK_PRIVATE/LINK_PUBLIC arguments of target_link_libraries() (or just PRIVATE/PUBLIC, as there where renamed in 2.8.12). This makes it possible to control which TPL libraries are exposed to the user.

[bartlettroscoe]

I am not really sure what this means because entirely I don't work with the CMake export files but it sounds good to me. How would this be used in TriBITS?

[nschloe]

Well, in the call to TARGET_LINK_LIBRARIES(), some of the libraries should be adding with a keyword prefixed. The package author has to decide if his package exports the interface of the dependent library (e.g., includes anything of it in the installed headers), and if it doesn't add it to PRIVATE_DEPLIBS rather than DEPLIBS. The same would have to be applied to TPLs. Not sure what to add there.

[bartlettroscoe]

Okay, so PRIVATE_DEPLIBS are used only is the implementation of the package and are not meant for users to directly link to? But if these libraries are used in the main "interface" library exported by the package, they still have to be installed, right? The real issue then is if the header file include paths for a given "private" package library are exported to other packages or if they are just used within the parent package for internal implementation purposes. We have the NOINSTALLHEADERS argument for listing headers that should not be installed, likely because they are part of the package's private interface. Should like name this PRIVATE_HEADERS then right? Likewise, when defining a private library with TRIBITS_ADD_LIBRARY(...), you would need to declare it as PRIVATE so that its header file include dirs don't get added to ${PACKAGE_NAME}_INCLUDE_DIRS? For that to work with the current system, PRIVATE libs would need to be defined in their own CMakeLists.txt file or all of the include directories added with INCLUDE_DIRECTORIES() would get picked up.

I think we may need to rename this Issue to get at the real intent w.r.t. TriBITS with what it is trying to accomplish. It will take some thought for how this fits in with TriBITS package's both for internal downstream client software and client's of the installed packages. Whatever we come up with has the same basic behavior both if the package is installed and then used, or if it is built in the same TriBITS meta-project.

[nschloe]

The only effect this keyword has (as far is I know) is that the target export files are cleaner. For example, the current export for teuchosnumerics of Trilinos contains

set_target_properties(teuchosnumerics PROPERTIES
  IMPORTED_LINK_INTERFACE_LIBRARIES_NONE "teuchoscomm;teuchoscore;/usr/lib/liblapack.so;/usr/lib/libblas.so"
  IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/x86_64-linux-gnu/libteuchosnumerics.so.11.11"
  IMPORTED_SONAME_NONE "libteuchosnumerics.so.11"
  )

i.e., it notifies other libraries that teuchosnumerics links against /usr/lib/liblapack.so. This information is unnecessary here since all linking info is contained in the shared library libteuchosnumerics.so.11.11 itself. Adding the PRIVATE keyword for LAPACK, BLAS will turn this into

set_target_properties(teuchosnumerics PROPERTIES
  IMPORTED_LINK_INTERFACE_LIBRARIES_NONE "teuchoscomm;teuchoscore"
  IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/x86_64-linux-gnu/libteuchosnumerics.so.11.11"
  IMPORTED_SONAME_NONE "libteuchosnumerics.so.11"
  )

The effect is that any library linking against TeuchosNumerics doesn't need search for LAPACK, BLAS. CMake is treating the cases of static linking correctly, too (in that if you link TeuchosNumerics statically, the dependent libraries are listed).

[bartlettroscoe]

But when static libraries are being used, then all of the link dependencies must be known.

Is the current form shown in the above example case a problem or is it just messy?

[nschloe]

Like I said, CMake reacts correctly the situation with static libs in that it does add the dependent libraries, even if declared PRIVATE.

[bartlettroscoe]

But wait, does not every link line that pulls in -lteuchosnumerics not also have to pull in -lblas and -llapack when static libs are involved? I guess I would have to see the full export files to see what info CMake really has.

[nschloe]

But wait, does not every link line that pulls in -lteuchosnumerics not also have to pull in -lblas and -llapack when static libs are involved?

That's what I'm saying it does.