Re: [Boost-build] Copy previous build target into current unit test directory

Subject: Re: [Boost-build] Copy previous build target into current unit test directory
From: Chambers, Matthew (matt.chambers42_at_[hidden])
Date: 2017-08-01 20:01:14

On 8/1/2017 11:53 AM, Steven Watanabe via Boost-build wrote:
> On 08/01/2017 09:55 AM, Chambers, Matthew via Boost-build wrote:
>> I am in a similar situation as the OP. I have a unit-test but don't see
>> an obvious way to copy my lib target's output to the unit-test
>> directory. I dug back through the archives and found this post as the
>> closest explanation of how to do what I want without making deeper
>> modifications to Boost.Build.
>>
>> The lib is a SQLite extension (shared object or DLL), so the unit test
>> needs to know the path to it to load it (and I'd rather avoid the
>> complexity of changing to a run target and passing the lib target as an
>> input file). This would apply to dynamic plugin systems in general, too.
>> Where do I put the @common.copy to get the lib copied? Do I have to
>> convert the lib target to a make target, or is the `make mylib.dll`
>> below supposed to be in addition to an implied `lib mylib` target?
>>
>    If you're using unit-test, then as long as
> the lib is in the same project and uses the
> same properties as the unit-test, it will be
> built in the same directory.

Thanks for the tip about making sure the properties are the same. My unit-test had a custom <location-prefix> and was <link>static 
(inherited from default-build) whereas the extension was of course <link>shared and didn't have a <location-prefix>. After matching those 
properties up ("<link>shared <library>extension/<location-prefix>foo" on the unit-test), it worked. However, this feels quite fragile! And 
of course as you mentioned it depends on them being in the same project.

Can Boost.Build have a built-in propagated free feature that acts like <dependency> but copies the depended-on target (or simple file) to 
the build directory? This would be very helpful on Windows for interacting with .NET, and would be useful for using/testing dynamic plugins 
as above. I actually hacked my own msvc.jam a long time ago to support an <assembly> feature which not only copies the file to the output 
directory, but also adds it to the compile command (/FU). Along with a few other customizations, this allows my BB to build C++/CLI. But my 
implementation was hacky so I haven't contributed it. I didn't know how to do it properly in BB and it seems that dynamic plugins need this 
to work for multiple toolsets.

Thanks!
-Matt