Thanks for clarifying. I must say I am not convinced by the usability argument. Having just the files of Y and not the build makes library X usable. And X is what the user asked for. So, from a usability point of view it is perfect.
How do you know Y is usable at that point? To get what you want, a packaging tool has to be given much more information. If Y depends upon a header from Z, how does the tool know whether that Z header implies the need to build Z? Without that, the tool must assume that Z will need to be built. The same applies to the Y headers upon which X depends so Y must be installed ready to build.
Is it really that much more information that needs to be given? If you would just tell the package manager which header files require building and which not, would that not enable it to remove many dependencies based on the assumption that all headers require building. If such information were absent you could always revert to the original assumption that everything needs to be build.
If the tool knows that a library is header only,
selective about which files it installs. However, that leads to complicated dependency tracking of the installed files. If the user gets only a
Well, large parts of BOOST are header-only and libraries that are not header-only often only rely on being built for some specific functionality. then it could be more partial Y It would be very complicated if you wanted to optimize and really copy only the files that are essential. However I suggest to only get complete libraries, but also only get libraries that are actually depended (based on recursive file dependencies) on and not all libraries that are depended on based on recursive library dependencies.
and a partial Z to satisfy X, and the user asks to install Y, the tool must install the rest of Y. But if the user then uninstalls Y, the tool must leave the parts of Y that were needed originally for X whilst removing the rest of Y.
That is why I thought it would be good to always get all files of a library, even if not all files are needed.
Since users can alter the contents of the installation directories, the tool must actually track all files it installs in order to be able to reinstall missing files to correct user mistakes, too.
Rob