Re: [boost] Critical. Help required. Boost.DLL Jamfile breaks testing with multiple toolsets

2015-09-05 0:14 GMT+03:00 Rene Rivera :

On Fri, Sep 4, 2015 at 3:04 PM, Antony Polukhin wrote:

...

2015-09-04 21:33 GMT+03:00 Rene Rivera :

...

They aren't linked. They are passed in as extra args. Re:

rule run ( sources + : args * : input-files * : requirements * : target-name ? : default-build * )

It's the "input-files" argument.

Thanks, this works. But unfortunately this method requires tests and examples to be rewritten. Also, is there a way to receive library name without a version ("libtest_library.so" instead of "libtest_library.so.1.59.0")?

Why? I ask because that's the file that it generates. So the question really is.. Why do you want to change the generated DLL?

Because in some tests there's a need to test the dll::load_mode::append_decorations flag. That flag appends platform specific decorations to the supplied path (changes "test_library" into "libtest_library.so"/"test_library.dll"/...) In other tests "libtest_library.so.1.59.0" is OK.

Solution with TEST_DIR seems friendlier to me. Could it be fixed somehow?

...

Not really.. Think about it how would we generate an appropriate directory to copy the DLLs into? And how would that differ from the build paths we already generate to build into? And if it doesn't differ, what's the point of another location?

Currently is generates single shared library in shared-library-specific build path. I wished to have a common path with shared libraries that is stable between toolsets. Anyway, thank you all for the help! I've fixed the Jamfile to use "input-files". This will probably fix the Android tests too, as Dmitry Moskalchuk noted. -- Best regards, Antony Polukhin