Re: [boost] big problem with dependency changes

Subject: Re: [boost] big problem with dependency changes
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-06-18 12:56:22

On 06/18/2014 10:51 AM, Paul A. Bristow wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Bjørn Roald
>> Sent: 17 June 2014 22:30
>> To: boost_at_[hidden]
>> 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