target_sources vs. PUBLIC_HEADER for libraries

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

target_sources vs. PUBLIC_HEADER for libraries

Michael Ellery
I’d like to make sure I understand two different aspects of header files management for libraries:

(1) typically you can add header files to target_sources, but it’s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actually need header files explicitly specified for dependency tracking, although I guess listing them makes it explicit.

(2) setting the PUBLIC_HEADER property for a target then makes header files available for installation via the PUBLIC_HEADER destination. Is this the preferred way to install the library interface/public headers? How do you handle a header directory hierarchy — for example maybe you have detail and impl subdirectories if you are following boost/stdlib conventions.

I found Craig’s article about target_sources very helpful (https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/), but I don’t think it addresses the PUBLIC_HEADER installation use case.

Thanks,
Mike Ellery
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: target_sources vs. PUBLIC_HEADER for libraries

fdk17


On Fri, Oct 11, 2019, at 3:33 PM, Michael Ellery wrote:
I’d like to make sure I understand two different aspects of header files management for libraries:

(1) typically you can add header files to target_sources, but it’s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actually need header files explicitly specified for dependency tracking, although I guess listing them makes it explicit.
My experience has been that adding a header file makes sure it’s listed in the IDE along with the other sources.   Some IDEs will determine other non-listed headers and list them under a different folder. But I’ve never seen listing an unused header file getting added as a dependency so that changing it causes the target to get rebuilt. I’ve always had to make sure that the header is included in something that gets compiled. 


F

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: target_sources vs. PUBLIC_HEADER for libraries

Alex Turbov
In reply to this post by Michael Ellery
Hi,

On Fri, Oct 11, 2019 at 9:33 PM Michael Ellery <[hidden email]> wrote:
I’d like to make sure I understand two different aspects of header files management for libraries:

(1) typically you can add header files to target_sources, but it’s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actually need header files explicitly specified for dependency tracking, although I guess listing them makes it explicit.

yep, correct


(2) setting the PUBLIC_HEADER property for a target then makes header files available for installation via the PUBLIC_HEADER destination. Is this the preferred way to install the library interface/public headers? How do you handle a header directory hierarchy — for example maybe you have detail and impl subdirectories if you are following boost/stdlib conventions.


Nowadays this feature useless if you have a directory hierarchy %( So pity...
 
I found Craig’s article about target_sources very helpful (https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/), but I don’t think it addresses the PUBLIC_HEADER installation use case.

Yep, it describes a trivial ("Hello World" level) projects.

Some time ago I've started a discussion about improvements to `target_sources` addressed to resolve directory hierarchy install problem, but it ends w/ no outcome... %(


Thanks,
Mike Ellery
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: target_sources vs. PUBLIC_HEADER for libraries

Innokentiy Alaytsev
In reply to this post by Michael Ellery
Hello!

After some look into target installation, I've devised  the following
abomination
<https://gitlab.com/UtilityToolKit/utk.cmake/blob/master/utk_cmake_install.cmake#L357>
. It is ugly and not the way it should be done, but it works and only
requires some discipline at copying and pasting header files listing code.
The function expects the files that are to be installed to be listed with
BUILD_INTERFACE and INSTALL_INTERFACE generator expressions.

I only use it for headers because I don't know how to separate file lists
into components (i.e. Dev for headers and Runtime for resource files
required at runtime). I use the following code for listing target header
files:

set (HEADERS
  # List of files here
  )

file(RELATIVE_PATH PREFIX
  ${PROJECT_SOURCE_DIR}
  ${CMAKE_CURRENT_LIST_DIR})


foreach (HEADER IN LISTS HEADERS)
  target_sources (my_target(s)
    PRIVATE
    $<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/${HEADER}>
    $<INSTALL_INTERFACE:${PREFIX}/${HEADER}>)
endforeach (HEADER IN HEADERS)

Hope that will somewhat help and won't hurt anyone's fillings and mind.

Best regards,
Innokentiy Alaytsev




--
Sent from: http://cmake.3232098.n2.nabble.com/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake