Clarifying PUBLIC_HEADER property and non-FRAMEWORK / STATIC / INTERFACE libraries

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Clarifying PUBLIC_HEADER property and non-FRAMEWORK / STATIC / INTERFACE libraries

Andrew Fuller-2

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

Please keep messages on-topic and check the CMake FAQ at:

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

CMake Support:
CMake Consulting:
CMake Training Courses:

Visit other Kitware open-source projects at

Follow this link to subscribe/unsubscribe: