If I use add_subdirectory(foo EXCLUDE_FROM_ALL), and do
install(FILES foo.h COMPONENT Devel), and then do a component-package with the tgz (ARCHIVE)-generator, it creates an empty Foo-Devel.tar.gz.
It is empty because the directory was added with EXCLUDE_FROM_ALL, so foo.h was not installed, that’s Ok.
But since the component “Devel” is empty, it shouldn’t create an empty package for it.
Where’s the correct place to fix that ?
In the place where EXCLUDE_FROM_ALL is handled, and skip components which are empty ?
Or in the place where the package is created, to skip installing components which are empty ?
Honestly, I would try to avoid installing anything from a directory that is excluded from the ALL target. There are holes in the logic around that, and you’ve probably stumbled on one of them. There have been other cases reported where the excluded content isn’t quite fully excluded in all situations, leading to failures because things that were expected to exist or be built, weren’t.
But to answer your question, if you want to avoid packaging an excluded component, you would need to explicitly set the CPACK_COMPONENTS_ALL variable to just the components you want to create packages for. You can get the full list of defined components from the CPACK_COMPONENTS_ALL pseudo property. For example:
I believe it is not a true property, it’s one of those weird pseudo properties that you can only read using get_cmake_property(). I don’t think you can retrieve it using get_property(). I don’t recall the full list, but I think there are a few pseudo properties like this (but it’s a small list).
COMPONENTS is not a global property, it is a pseudo property that you cannot read with get_property(). If we list COMPONENTS as a global property, I guarantee people will try to read it with get_property() and wonder why they get back an empty string. If we add it to the properties page in the docs, it would need to be in its own new separate section, and it would have to somehow make clear that properties in this new section are special, not global properties.
I agree it’s not very discoverable at the moment. I don’t know that making the pseudo property more visible its current state is a great outcome, it may create as many problems as it solves. Perhaps it would be worth exploring whether get_property() can be extended to support reading pseudo properties and we deprecate cmake_property(). But I suspect there are negative performance implications if we were to do that. This would be something that’s more @brad.king’s call.