On 06/18/2014 10:51 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bjørn Roald Sent: 17 June 2014 22:30 To: boost@lists.boost.org Subject: Re: [boost] big problem with dependency changes
Moral of the story: don't edit the files in boost/.
The exceptions are the headers which b2 can't see as dependencies - those included via a macro. They never get their links updated unless one runs "b2 headers". We've fixed some of them, but not all.
Good! but even if all are fixed, it is not good to have these subtle issues where users have to be careful. Part of the problem is that many tools such as IDE's with built-in symbol browsing, debugers etc. will lead users to those headers they should not edit.
To me, this seems a *big* problem :-(
Agree, I for one do not want to down-grade the severity of this.
I'd fail the whole idea of using hard or symlinks without some method of protecting the poor unsuspecting hapless users from this elephant trap.
I think symlinks will protect you just fine, and it is supported by b2. So it is not bad at all for users where b2 can use symlinks :-) The problem is to enable symlink support in a simple robust way that does not sacrifice security for users that dont have this by default. On Windows I fail to find a way. I think solving that should be a primary goal now, but it seems we need more detailed understanding of Windows privileges and UAC than I posses. I wonder: Could we possibly write or download an executable that work around this UAC strap-down and create symbolic links for Windows users in the Administrator group that has the SeCreateSymbolicLinkPrivilege set. If that is possible, then a sensible workaround would be feasible. I worry it is not possible, but I will be happy if I am wrong. Down the road there are other options than staging of headers in the legacy monolithic boost folder structure. This may be achieved relatively simply by module level dependencies and multiple -I statements to the compiler. But this approach has its own set of disadvantages and a number of boost tools are not ready for it. There are probably a few pitfalls as well with dubious workarounds, e.g. command line limitations on some systems. End users will likely always be better off with a deployed set of selected boost modules with a single boost header file structure. So that will be simpler with a deployment system that is not using the git repositories. But as some pointed out, they are expected to download, possibly build boost once, then use. So as long as they don't overwrite their copy of an old release, there is no problem. If they do, then it is reasonable to require a b2 clean or similar. -- Bjørn