On 28/05/2017 04:08, Peter Dimov wrote:
The objection is that the non-preprocessed form, which is more convenient when one needs to look at the implementation, study how it's organized, fix a problem one's having (on mignw64, for instance), then prepare a pull request, does not compile unless one has a foreign submodule installed, which in turn picks up two more, even more foreign, submodules.
It's not possible to have foreign submodules in a Boost distribution, so the choice there would be to either not provide the non-preprocessed form at all, or provide it in a non-functional form.
Presumably the Boost archive distribution form would have the source code from the submodules "baked in". They're just subdirectories that contain files, after all. (ie. the Boost archive generator just needs to do that submodule update, then it can forget that they were submodules to start with. It might already be doing this, since the top-level uses submodules.) Only the users of the git repo need to care that submodules exist (and they should know how to deal with them, as this is standard git); users of the zip just get files and they don't care where they came from. Though the downside of this is that it will inevitably duplicate the code in the pre-processed header, and perhaps confuse users about which one to include or which one needs to be corrected in case of problems. Though in the latter case if someone submits a pull request against the pre-processed version it will be up to Niall to locate and correct the corresponding non-pre-processed version accordingly; that's just a natural consequence of choosing to distribute the source in that form.
Yes, and I already answered it, with your swiftly proceeding to ignore my answer. Probably because you didn't understand it, which of course means it's irrational.
To repeat, it's not possible for a Boost user to not want a dependency on Boost. A Boost user already has Boost. This is tautological.
Yes and no. While this is true on the surface there is a deeper meaning to it when you probe. What you'll probably find is that the "Boost user who doesn't want Boost" actually just wants to avoid certain sub-libraries, eg. using C++11 types instead of Boost types, or avoiding MPL, etc. I don't think anyone objects to depending on the core (Config, Core, and Exception, mostly). Or if they do, they need their head examined.