From: David Abrahams (dave_at_[hidden])
Date: 2004-12-25 16:36:00
Vladimir Prus wrote:
> On Thursday 23 December 2004 21:25, David Abrahams wrote:
>> > I have /space/NM/boost which is shared between several folks (it's built
>> > once in several configuration). Then I have /home/ghost/Work/nm_model
>> > which uses /space/NM/boost. When running with --clean
>> > in /home/ghost/Work/nm_model, /space/NM/boost is cleaned too.
>> > Most of the time, it's not desired. When I do it, I just clean too much.
>> > When other folks do it, they get "permission denied" messages.
>> My point is that (it seems to me) where things are placed and what will
>> get cleaned can and probably should be orthogonal questions.
> but my primary point was not in specific placement, it's the fact that -
> - build directory for one project is "shared"
Among its subprojects? Among its dependents?
> - the project is not modified often
> So, cleaning that project when doing --clean in dependent project is not good
I have no argument there, as I've been trying to tell you!
But I still don't see why it's relevant to what we were talking about.
-- I'm sorry, I'm confused about why anything explicit should have to be said about which properties are relevant. In BBv1 the flags rule took care of making properties relevant. You might only need to augment that information in a few rare cases. -- You said: -- Hmm... I was not aware of that, and you did not tell that in previous discussions. I think such automatic detection is very well possible. There's one question though. In past, Jurgen said that at least for him it's better to have everyting built in separate directories. Say, if bison produces files to "bin", them "bjam --clean release" will clean those files too, and he did not like this. Do we need yet another option? -- You seem to be connecting this problem of cleaning the wrong stuff with the problem of detecting feature relevance. I still don't see the connection, which is what I've been saying to you for the past few messages in this thread. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk