Critical. Help required. Boost.DLL Jamfile breaks testing with multiple toolsets
Hi, There's a big problem with Boost.DLL's Jamfile which I do not know how to fix. Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there: path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ; project : source-location . : requirements ; { # our test lib for shared library tests lib test_library : test_library.cpp : <link>shared ; lib getting_started_library : ../example/getting_started_library.cpp : <link>shared ; install install-bin : test_library getting_started_library : <location>$(TEST_DIR) ; test-suite boostdll : [ run shared_library_load_test.cpp : $(TEST_DIR) : : <dependency>install-bin ] [ run shared_library_search_symbol_test.cpp : $(TEST_DIR) : : $(RDYNAMIC) <dependency>install-bin ] ; } The Problem If multiple toolsets specified, then `install-bin` target gets broken: cd libs/dll/test ../../../b2 toolset=gcc,clang error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxflags>-Wall -Wextra -pedantic -Wno-long-long <library>object(file-target)@3829 <library>object(file-target)@3862 toolset-gcc:version4.8 <toolset>gcc <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/gcc-4.8/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/gcc-4.8/debug/threading-multi error: - <library>object(file-target)@7264 <library>object(file-target)@7296 toolset-clang:platformlinux toolset-clang:version3.4 <toolset>clang <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/clang-linux-3.4/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/clang-linux-3.4/debug/threading-multi Correct fix would be to embed into TEST_DIR the names of toolset and all other configuration flags. path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test/$(FLAGS)/$(TOOLSET) ; The Question How to get the $(FLAGS) and $(TOOLSET) variables? If that requires writing rules or implies some other Boost.Build magic I'd really appreciate a pull request: any nontrivial modification to Jamfile takes months to apply and test because of my poor knowledge of Boost.Build. Jamfile: https://github.com/boostorg/dll/blob/develop/test/Jamfile.v2 Boost.DLL: https://github.com/boostorg/dll This issue is critical, because it breaks regression testing (see "[boost] [android][regression] bjam failed") -- Best regards, Antony Polukhin
AMDG On 09/04/2015 11:12 AM, Antony Polukhin wrote:
There's a big problem with Boost.DLL's Jamfile which I do not know how to fix.
Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there:
path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ;
Don't do this. In addition to the problem that you're having, this effectively overrides a command line build-dir option. Instead of passing the directory, you should pass the targets, like this: run shared_library_load_test.cpp : # args : getting_started_libary test_library ; In Christ, Steven Watanabe
2015-09-04 20:38 GMT+03:00 Steven Watanabe
AMDG
On 09/04/2015 11:12 AM, Antony Polukhin wrote:
There's a big problem with Boost.DLL's Jamfile which I do not know how to fix.
Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there:
path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ;
Don't do this. In addition to the problem that you're having, this effectively overrides a command line build-dir option.
Instead of passing the directory, you should pass the targets, like this:
run shared_library_load_test.cpp : # args : getting_started_libary test_library ;
Library *must not* be linked to the test. Those are not actually libraries, those are plugins, that must be searched by test and loaded using the Boost.DLL. -- Best regards, Antony Polukhin
On Fri, Sep 4, 2015 at 1:22 PM, Antony Polukhin
2015-09-04 20:38 GMT+03:00 Steven Watanabe
: AMDG
On 09/04/2015 11:12 AM, Antony Polukhin wrote:
There's a big problem with Boost.DLL's Jamfile which I do not know how
to
fix.
Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there:
path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ;
Don't do this. In addition to the problem that you're having, this effectively overrides a command line build-dir option.
Instead of passing the directory, you should pass the targets, like this:
run shared_library_load_test.cpp : # args : getting_started_libary test_library ;
Library *must not* be linked to the test. Those are not actually libraries, those are plugins, that must be searched by test and loaded using the Boost.DLL.
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. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
2015-09-04 21:33 GMT+03:00 Rene Rivera
2015-09-04 20:38 GMT+03:00 Steven Watanabe
: AMDG
On 09/04/2015 11:12 AM, Antony Polukhin wrote:
There's a big problem with Boost.DLL's Jamfile which I do not know
how to
fix.
Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there:
path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ;
Don't do this. In addition to the problem that you're having, this effectively overrides a command line build-dir option.
Instead of passing the directory, you should pass the targets, like this:
run shared_library_load_test.cpp : # args : getting_started_libary test_library ;
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")? Solution with TEST_DIR seems friendlier to me. Could it be fixed somehow? -- Best regards, Antony Polukhin
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")?
Just FYI: this solution also automatically fixes testing on Android - adbrunner tool automatically detect files passed as command line arguments and upload them to device before running tests. -- Dmitry Moskalchuk
On Fri, Sep 4, 2015 at 3:04 PM, Antony Polukhin
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? 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? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
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
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")?
OK, the solution works for Linux but fails on Windows. In Jamfile I'm explicitly requesting to build shared library: lib my_plugin_sum : ../example/tutorial1/my_plugin_sum.cpp : <link>shared ; lib my_plugin_aggregator : ../example/tutorial2/my_plugin_aggregator.cpp : <link>shared ; But when I'm feeding those libraries to the test as input files: [ run ../example/tutorial3/tutorial3.cpp : : my_plugin_aggregator my_plugin_sum ] I recieve the following 2 first parameters, one of which is a static library: "D:\boost\bin.v2\libs\dll\test\msvc-12.0\dbg\adrs-mdl-64\thrd-mlt\my_plugin_sum-vc120-mt-gd-1_60.dll" "D:\boost\bin.v2\libs\dll\test\msvc-12.0\dbg\adrs-mdl-64\thrd-mlt\my_plugin_sum-vc120-mt-gd-1_60.lib" Is there a way to receive only shared libraries via input-files? -- Best regards, Antony Polukhin
On 09-Sep-15 10:11 PM, Antony Polukhin wrote:
In Jamfile I'm explicitly requesting to build shared library:
lib my_plugin_sum : ../example/tutorial1/my_plugin_sum.cpp : <link>shared ; lib my_plugin_aggregator : ../example/tutorial2/my_plugin_aggregator.cpp : <link>shared ;
But when I'm feeding those libraries to the test as input files: [ run ../example/tutorial3/tutorial3.cpp : : my_plugin_aggregator my_plugin_sum ]
I recieve the following 2 first parameters, one of which is a static library: "D:\boost\bin.v2\libs\dll\test\msvc-12.0\dbg\adrs-mdl-64\thrd-mlt\my_plugin_sum-vc120-mt-gd-1_60.dll" "D:\boost\bin.v2\libs\dll\test\msvc-12.0\dbg\adrs-mdl-64\thrd-mlt\my_plugin_sum-vc120-mt-gd-1_60.lib"
Is there a way to receive only shared libraries via input-files?
Antony, I would presume your test can look at the first parameter only, and that would be a quick fix for you? We have pull request for DLLs with no associated lib file, at: https://github.com/boostorg/build/pull/28 However, that pull request was adding support for resource-only DLLs, and likely will break plugin DLLs, and no revised version was submitted so far. If adjusting test case is not an option, I probably can write you custom code to filter out lib target. - Volodya
participants (5)
-
Antony Polukhin
-
Dmitry Moskalchuk
-
Rene Rivera
-
Steven Watanabe
-
Vladimir Prus