Re: [boost] [serialization] Fix Jamfile

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