Re: [jamboost] QT support, and some problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 08:15:40

Jürgen Hunold wrote:

>>Thanks for trying!
> 
> 
> You're welcome. Well, the point is that I think bjam V2 will be superior 
> to qmake. And I'm happy to contribute a little to the develop.

Nice to hear that.

>>>The answer is to hadrcode the library with -Wl,-rpath, for gcc.
>>>
>>
>> > Another change is to link against qt-mt (Multi-Thread).
>> > I wonder about detecting this somehow...
>>
>>What should be detected? The need to -Wl,-rpath, or multitheaded QT?
> 
> 
> Well, hardcoding the library-path is always good, at least for 
> development. I guess this should either be made default or a 
> configuration switch. 

The current situation is:
1. All libraries are shared by default
2. -rpath is not passed

However, there's "hardcode-dll-paths" property. When it's set, for each linked 
executable, paths for each library is added to -rpath. For example, if you
go to examples-v2/libraries and run

bjam hardcode-dll-paths=true

there, then you'll be able to run

app/bin/gcc/debug/main-target-app/app

without adjusting LD_LIBRARY_PATH.

> Multithreaded Qt depends on a multithreaded configuration. The qt 
> toolset should select qt-mt depending on the feature <threading>multi.
> So no autodetect is needed.

Noted.

>>>BTW, how do I link against external libraries ? I would need
>>>STLport i order to test with something real ? I've tried to figure
>>>out something from boost.python Jamfile.v2, but did not succeed.
>>
>>Oh... well... that's undocumented. Let me try to explain this in
>>email. I'll add it to docs after that.
> 
> 
>>Is this explanation appropriate?
> 
> 
> I'll try out later. Maybe this evening I fear. Have to get some work 
> done...

OK.

- Volodya