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. If a library has some aspects which depend on serialization, then those components/tests (and only those) should be made dependent on the serialization library. (mulit-index perhaps). If and only if the testing system has a functioning serialization library, The related tests will be run. Components and tests which do not depend upon the serialization library will still be run. The test results table will contain pass/fail/ blank - blank meaning "not applicable" This is as it should be.
Furthermore, due to the way Boost is build, this dependency can be added to basically all libraries, which is hardly needed.
I don't know what that means.
Because of that, I have removed usage-requirements setting on trunk.
Which, given my observations above, looks to be mistake to me.
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. 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). 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.
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost