Robert Ramey wrote:
Vladimir Prus wrote:
Robert,
in revision 43697 you have added usage requirements to serialization's Jamfile, as follows:
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:
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