Re: [jamboost] V2 testsuite improvements

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-26 14:43:59

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > Here's a part of builtin.respose-file:
>> >
>> > if $(sources[2-])
>> > {
>> > response-file-2 $(target) : $(sources[2]) ;
>> > }
>> >
>> > I think you meant $(sources[2-]) in the second case too ;-)
>>
>> Nice catch. Now we have:
>>
>> dependency_test : 
>> "c:\boost\tools\build\test\..\jam_src\bin.ntx86\bjam
>> -sBOOST_BUILD_PATH=c:\boost\tools\build\test\..\new;c:\boost\tools\build\te
>
>> LINK : fatal error LNK1181: cannot open input file 'bin\msvc\debug\d.lib'
>> ...failed updating 1 target...
>>
>
>> The problem here is that y.cpp has nothing in it to export, so the
>> linker helpfully decides not to create an implib.
>
> What is needed to persuade it? A symbol marked with
> __declspec(dllexport)?

I believe so.

> Could you try modifying dependency-test/foo.jam so that it creates non empty 
> file, and see if this fixed the problem.

Of course I tried to do that, but I couldn't figure out where y.cpp
was coming from ;-)

>> BTW, we're going to have to deal with __declspec(dllXXport) somehow if
>> these tests are going to work on MSVC :-S
>
> :-( I'm thinking that we can use macro called DLLEXPORT and automagically pass
> appropriate <define> property to bjam invocations. Sounds dirty... but no 
> better insights yet.

Usually you want a separate macro associated with each target, whose
meaning changes based on the target name. So, in a single header:

// impexp.hpp
#ifndef _Win32
# define SHARED_SYMBOL(lib_id)
#else
# define SHARED_SYMBOL(lib_id) __declspec(BOOST_PP_IF(lib_id##SOURCE,dllexport,dllimport))
#endif

// foo.h
#include "impexp.hpp"
void SHARED_SYMBOL(FOO_) foo(char*);

Then you put <define>FOO_SOURCE in the requirements for foolib.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com