Robert Ramey wrote:
Say library A depends on serialization. Serialization itself depends on config/whatever. Then, if config/whatever fails, the serialization build 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" means.
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: requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE usage-requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE 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 should not require any of this. I also find it hard to imagine any local misconfiguration that might cause this. What are the exact error message 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 fine.
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 XXX", 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. - Volodya