I'm finding the PUBLIC_HEADER target property to be quite convenient for clarity's sake. Specifically it spells out quite unambiguously that "hey, these are the headers I want to be published" while at the same time providing locality to the export details with "PUBLIC_HEADER DESTINATION foo" and "INCLUDES DESTINATION foo". Less code by not needing a separate "install( FILES … )" stanza is a bonus.
The documentation for the PUBLIC_HEADER property seems to stress (framework) shared libraries. I'm left wondering if I'm abusing PUBLIC_HEADER by using it on static libraries as well. Am I going to get bit down the road by doing this, or is this use perfectly acceptable? Assuming it's fine to use on static libraries, then how about interface libraries? I see there have been previous discussions on the mailing list about whether more properties should be whitelisted for interface targets, but I didn't see PUBLIC_HEADER brought up. Updating the interface includes directory using the "INCLUDES DESTINATION foo" when exporting an interface library already works, so it would be very nice to be able to leverage PUBLIC_HEADER at the same time. Again, for clarity/consistency/less code. Is there a technical limitation, or is it just a matter of adding public_header to the whitelist? For now I've just got an extra "install( FILES … )" stanza. Thanks in advance.
-- 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: http://public.kitware.com/mailman/listinfo/cmake
