Re: [jamboost] QT support, and some problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-21 01:15:01

Jürgen Hunold wrote:
> Am Montag 20 Januar 2003 14:15 schrieb Vladimir Prus:
> 
> 
> 
>>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.
> 
> 
> Well, I've converted one build from qmake to bjam. It took 45 minutes 
> and worked fine. The problem with <hardcode-dll-paths> seems to be that 
> it only hardcodes user.specified libraries following the "exe : " rule.
> The qt is not hardcoded. 

Yes, because qt is *directly* addeed to linker flags. If qt were declared in
the regular way (using "lib" rule), path to it would be hardcoded as well. But
declaring qt library in regular way requires some changes. I hope to get to
it by next week.

> Is there any reason why I have to specify the "lib" prefix on unix 
> libraries in v2 ? V1 did this by automatic, so declaring libfoo was 
> done by writing: "lib foo :" Now I have to write "lib libfoo :" which 
> is extra work and leeds to confusion when building on win32, where you 
> have the ".lib" postfix...

Since V2 did not yet recieved as much attention as V1, this feature was simply
forgotten/ignored. If this is needed, we have to devise a clean way. In the 
meantime, it should suffice to change lines 40 and 41 of gcc.jam to read:

generators.register-composing gcc.archive : OBJ : STATIC_LIB(lib%) : 
<toolset>gcc ;
generators.register-linker gcc.link-dll : OBJ : SHARED_LIB(lib%) : <toolset>gcc ;

That's really bad trick, but all possible for now.

- Volodya