On January 10, 2015 4:43:20 PM EST, alex <alexhighviz@hotmail.com> wrote:
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.
If the library was header only and now must be built, that's a breaking change and might make the maintainer recall the need to change the metadata for the library. Detecting the missed metadata change will be relative easy: link failures well occur if someone installs and use that package. There's no way to automate checking that unless test runners is the packaging tool for each library under test. Changing one file from not requiring building a library to requiring that it be built, for a library that already needed to be built is a likely failure case. The maintainer is likely to forget to change the metadata for that file and detecting its omission will be difficult.
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.
Sure
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 not obvious. Users can install Boost on a host that already has another version installed by an administrator, for example. A user might install more than one version.
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?
Yes, but you're not thinking about users changing their minds, it seems.
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.
Yes, but very solvable and I would think it already needs to do this anyway.
That implies an extra directory associated with the tree to hold that information. That data can be stale relative to the filesystem which implies an integrity checker and a healing mode, etc. These are all complications which Peter, or even Boost, may not wish to undertake. However, if you're volunteering, I'm sure Peter would welcome your help.
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 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?
That's a nice first step, but even then you're relying on library maintainers to remember yet another thing to update, and that for an infrequent state change. ___ Rob (Sent from my portable computation engine)