From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-03-19 14:18:02
Robert Ramey wrote:
>> Say library A depends on serialization. Serialization itself depends
>> on config/whatever. Then, if config/whatever fails, the serialization
>> will fail. Then, in turn, will cause library A build to fail.
>> So, no test for library A will run, either.
> Correct - that is as it should be. If A depends on serializaiton
> and serialization depends upon config/whatever, and config/whatever
> fails, then there is no point in running/testing serialization nor
> anything that depends upon it. That's what "dependency"
>> Can you, in light of above, clarify exactly will target will
>> be build when it should not be built?
> To repeat. in this example, building A would be a mistake
> as it depends on something that is known not to work.
> Building A under these circumstances is at best a waste of
> resources and at worst very missleading.
Your Jamfile had two things:
The first if just enough, as far as I can see. Why did you add the
second? Do I miss any case where the first one is not sufficient?
>> Hmm, a commit that fails because a post-commit hook rejects commit
>> not require any of this. I also find it hard to imagine any local
>> misconfiguration that might cause this. What are the exact error
>> you get from SVN?
> I reported one of them on this list when it occurred. There was no
> response. It was complaining about a mime-type.
There was a response; Stefan has wrote:
There is neither a 'mimi-type', nor a 'mim-type', but a 'mime-type'. May
be it works with that spelling ?
> I tried everything
> to address it. Finally I created a new directory and made a new
> update then retried the operation (adding a new file) and it worked
>>> Sometimes the checkin reports
>>> error but in fact does show up in th SVN browser, etc. On occasion,
>>> the check-in is reported as successful on my system but in fact
>>> didn't show up on the server (e.g. ../util/test.jam).
>> This is just impossible. When SVN client reports "Comitted revision
>> it means the transaction is done on the server. It cannot disappear
>> without some admin work (if if that admin work is done, your local
>> copy will broken beyond repair). Or do you mean Trac SVN browser?
>> That might in theory introduce some delay, but I never noticed it.
> LOL. I'm just reporting what I observed. Of course, you're free to conclude
> that my observations might have been mistaken, but I assure you, I'm not
> making this up. The offending file WAS missing
Was missing where? In a fresh svn checkout, or in Trac, or in
output of "svn ls <reporsitory url>"?
> and it was shown on
> my local machine with a green checkmark indicating that it was in sync
> with the server. - which is why I assumed that it was checked in
> which was why the whole problem occurred.
Oh, you're using some GUI. It might be acting up, then.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk