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

Subject: Re: [boost] Critical. Help required. Boost.DLL Jamfile breaks testing with multiple toolsets
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-09-06 16:06:02

2015-09-05 0:14 GMT+03:00 Rene Rivera <grafikrobot_at_[hidden]>:

> On Fri, Sep 4, 2015 at 3:04 PM, Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
>
> > 2015-09-04 21:33 GMT+03:00 Rene Rivera <grafikrobot_at_[hidden]>:
> >
> > > 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