[boost] Re: Questions re Jamfile for testing

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-12-04 12:18:26

Robert Ramey wrote:
> I've been making adjustments to the serialization library to permit it to be
> used as a DLL and I have a couple of questions.
> 
> As an example, I looked at the Jamfile for testing the filesystem.  It
> contains:
> 
>    test-suite "filesystem"
>        : [ run libs/filesystem/test/path_test.cpp
>                <lib>../../../libs/filesystem/build/boost_filesystem
>                :  :  : <define>BOOST_ALL_NO_LIB=1
>          ]
> ...
> 
> a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation
> of the libraries. Is this correct?

Yes.

> b) the requirements included <lib> ... but not <dll>. Does this test Jamfile
> EVER test the dll version of the filesystem library?

No it never does, and perhaps it should, but that's up to Beman.

> Now suppose the test is built with runtime-link/dll .  I believe that would
> indicate that the msvc dll version of the C++ libraries will be used and the
> compiler will compile code accordingly.  On the other hand the <lib> above
> suggests that this test should be built with static linking. 

Why does it suggest that? It's perfectly acceptable, and common, to use 
the dynamic runtime in a link library.

> This raises a
> couple of questions:
> 
> a) b) would it not make more sense for the filesystem test use the dll
> version of the library when the dll version of the c++ library is being
> used?  

Why?

> By the same token I would expect that if the static version of the
> c++ library is being used, then the static version of the filesystem library
> would be used. 

Again, why?

> Of course this isn't a requirement, but just a presumption
> that the most likely scenario is that a user that wants to use C++ libraries
> in dll from would likely want the same for other libraries.

Ah, it's a presumption... What you are saying is that we should globally 
mandate that tests be performed such that DLLs be tested only against 
the dynamic runtime and and LIBs against the static runtime. What about 
the users of LIBs that use the dynamic runtime? (I'm one of those)

> c) ideally, if we had nothing but time I would like to be able to test all
> combinations debug/release <runtime-link>static/dynamic, <filesystem
> library>static/dynamic.  What would be the most convenient way to do this.

1. Make sure that there are both <lib> and <dll> tests. (program_options 
currently does it)
2. Run the test with "-sBUILD=debug release 
<runtime-link>static/dynamic". Which will build 4 variants.

2b. Or if you are also interested in threading you can run the test with 
"-sBUILD=debug release <runtime-link>static/dynamic 
<threading>single/multi". Which will build 8 variants, if supported by 
the toolset.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq