On 7 January 2015 at 15:19, Peter Dimov
Daniel James wrote:
FWIW I'm fine with moving hash_fwd.hpp into core, or somewhere else. Its intent was always to break the dependency on the rest of the hash implementation, and if the dependency system can't understand that, then it isn't doing its job.
Creating a dependency system that will live up to everyone's expectations is not as easy as it sounds. To take hash_fwd as an example, suppose X uses hash_fwd.hpp, and Hash uses Y. The user installs X, which has to install Hash to get hash_fwd.hpp. Since the package Hash is now installed, it is listed in index.html, the users sees it as available, and tries to make use of it. If Y was not installed along with it, use of Hash would fail, and this isn't user friendly.
I meant the header isn't doing its job, which is why I was saying it's okay to move it into core, as that would fix the problem you're describing.
You can get this behavior today, if you move hash_fwd.hpp to a submodule hash/fwd, but since the installer operates on packages, and hash/fwd is in the 'hash' package, the problem I outlined above will manifest. (Even if we ignore the fact that Hash is actually in the package 'functional', so things are even more coarse-grained than that.)
Hash isn't the package 'functional', it's in the git submodule 'functional'. I'm certainly not having a git submodule just for one header. They're way too expensive.