Re: [boost] big problem with dependency changes

Subject: Re: [boost] big problem with dependency changes
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-06-19 12:15:42

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Bjørn Roald
> Sent: 18 June 2014 17:56
> To: boost_at_[hidden]
> Subject: Re: [boost] big problem with dependency changes
> 
> 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. 

I agree that this is most desirable - or even essential?

> 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.

Another complexity I fear is that requiring use of Admin privileges is that it
mean users cannot use tools like Tortoise GIT but must use  a GIT command line
from an elevated privs GIT Bash session.

Enforcing command-line only really isn't acceptable, even for library authors. 

Or is it only running b2 headers that is the problem?

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]