Re: [boost] [serialization] Fix Jamfile

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-03-19 13:17:29

Robert Ramey wrote:

> Vladimir Prus wrote:
>> Robert,
>>
>> in revision 43697 you have added usage requirements
>> to serialization's Jamfile, as follows:
>>
>> http://tinyurl.com/2hbzyu
>>
>> It appears that this change is not necessary. If
>> any other target depends on serialization, then it
>> will implicitly depend on serialization's dependencies.
> 
>> Adding <dependency> to usage requirements will mean
>> that if I have a library depending on serialization,
>> than that library will also have dependency on
>>
>> ../../config/test//BOOST_NO_STD_LOCALE
>>
>> If my library does not use that, there's no reason why
>> it should have a dependency.
> 
> Boost serialization currently depends upon correct functioning
> of std::locale. Â If your library depends upon boost serialization
> it necessarily depends upon correct functioning of std::locale.
> There's no getting around that.
> 
> If you commment out this dependency and run tests on your library,
> you will find all the tests related to boost serialization will fail due
> to either a failure to build the library or a failure of tests to compile
> or problems detected at run time. Â In any event, you will have expended
> a great amount of testing resources building and testing code which
> is apriori known to fail and generate a table which will show errors
> in your tests related to serialization. Â A cursory examination might
> lead one to conclude that this table shows errors either in your library
> or in the serialization library. Â Of course these conclusions are incorrect.
> 
> So - if a library depends upon serialization - (perhaps MPI) it will not
> build/tests if serialization cannnot be built/tested - this is as it should
> be.

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.

>> Because of that, I have removed usage-requirements setting on trunk.
>>
> 
> Which, given my observations above, Â looks to be mistake to me.

Can you, in light of above, clarify exactly will target will
be build when it should not be built?

>> Also, I've noticed that you have about 10 commits, all having
>> the same commit message:
>>
>> Support serialization in DLLS
>> Make thread-safe
>> fix portable binary archives
>>
>> It does not seem a good practice, as it's hard to understand what
>> each given commit was meant to do. Can you try to use descriptive
>> messages for each commit. FWIW, good guidelines on writing
>> commit messages can be found at:
>>
>> http://subversion.tigris.org/hacking.html#log-messages
> 
> This commit involved changes in quite a few files. Â The comment describes
> the motivation for the changes. Â If I do a large SVN check-in to the boost
> SVN from my system (a windows/XP system) it never completes without some
> sort of cryptic message/complaint. Â This has to be fixed using various means
> such as doing clean up and trying again, or by creating a now directory,
> updating, merging and trying again, etc. Â 

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?

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

> So, what should be an atomic check-in of a group of files cannot be done. Â I
> assigned the same comment to all the check-ins in order to highight the fact
> that they are all related. Â I did have a look at the link above which I
> hadn't seen before. Â I think the comment fairly captures the motiviation for
> the changes.

Except that the comment gave me no clue whatsoever why Jamfile.v2 was
changed the way it was. And it was not like I was browing history for no
purpose, instead, I was researching a build failure reported by a user:
http://svn.boost.org/trac/boost/ticket/1698

- Volodya