Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-03-19 13:09:13


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.

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk