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
> 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 A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk