On January 10, 2015 11:04:29 AM EST, alex
To get what you want, a packaging tool has to be given much more information. If Y depends
header from Z, how does the tool know whether that Z header implies
upon a 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.
There must be information on each file, at least if the library isn't marked header only. Both pieces of information can become stale after just one maintenance change, so it is brittle. There's also the question of where to store that information. Is it per host? per user?
If the tool knows that a library is header only,
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.
selective about which files it installs. However, that leads to complicated dependency tracking of the installed files. If the user gets only a
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.
I was trying to imply that, indirectly, but the tool will need to be smart enough to know when the user expressly wanted Y versus needing Y because of X.
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.
That would still be an issue. ___ Rob (Sent from my portable computation engine)