From: Robert Ramey (ramey_at_[hidden])
Date: 2008-03-19 13:09:13
Vladimir Prus wrote:
> 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
> 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
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
a functioning serialization library, The related tests will be run.
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
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
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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk