If you would just tell the package manager which header files require building and which not....
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.
Yes you would need information for each file, but you could have defaults for the library or directories. Would you call a code change that introduces a requirement to build 'maintenance' ? It would be a breaking change for users that did not build before. A code change that removes a requirement to build but not marked as such would not cause a problem; it just means that sometimes the library would be built superfluously.
There's also the question of where to store that information. Is it per host? per user?
Isn't it obvious that it should be per host? The user shouldn't be expected to know?
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.
Isn't the whole idea that the users express what they want and then get the package containing what they need?
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.
From you responses I gather that resolving dependencies at file level would cause too many complications for built libraries but not so for header-only
Yes, but very solvable and I would think it already needs to do this anyway. libraries. Why not at least take advantage of the header-only status of a large number of libraries? I suppose this would create an incentive to split existing libraries into a built and header-only library, but that is not so bad is it?