Re: [jamboost] QT support, and some problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 05:49:35

Jürgen Hunold wrote:

> Thanks ! I've tried and it links fine. Execution is another matter, for 
> I use a customised Qt which is not in ld.so.conf nor in LD_LIBRARY_PATH 
> due to conflicts with KDE-3.x.

Thanks for trying!

> 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?

> RCS file: /cvsroot/boost/boost/tools/build/new/qt.jam,v
> retrieving revision 1.2
> diff -u -r1.2 qt.jam
> --- qt.jam	20 Jan 2003 09:25:53 -0000	1.2
> +++ qt.jam	20 Jan 2003 10:02:10 -0000
> @@ -41,7 +41,7 @@
> 
> rule qt.add-properties ( property )
> {
> - return <include>$(.prefix)/include <linkflags>-L$(.prefix)/lib 
> <linkflags>-lqt ;
> + return <include>$(.prefix)/include 
> <linkflags>-Wl,-rpath,$(.prefix)/lib <linkflags>-L$(.prefix)/lib 
> <linkflags>-lqt-mt ;
> }

Applied. Thanks!

>>>I had a look at the Jamfile and it looks very good and seems to be
>>>very easy to use. However, as several people, among them yourself,
>>>pointed out in the thread "Adding QT support to Boost Build V2" it
>>>really isn't a good idea to introduce that ".qpp" extension. As I
>>>already explained to Jürgen, the moc can be seen as a tool in the
>>>spirit of Doxygen that processes regular C++ files and extracts
>>>information from them. So leaving the header file extension at ".h"
>>>(or ".hpp", maybe) actually does make more sense from that point of
>>>view. After all, we don't want to use a different extension for
>>>each header file that is to be processed by a certain tool.
>>
>>OK, I'll change that.
> 
> 
> Thanks ! 
> 
> I'll try and compile some other simple tools if you have finished the 
> change.

Done. examples-v2/qt now uses "h" suffix.

> 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.

If you want to link against prebuilt library, you should use the "lib" target,
with some variation:
1. You don't specify sources
2. You specify <name> property, which tells that the library should be found 
via "-l" option

lib stlport : : <name>stlport ;

You can also tell the paths where the library should be searched:

lib stlport : : <name>stlport <search>/home/ghost/local/bin ;

Is this explanation appropriate?

We should really implement the stlport support. I've started already. Adding 
relavant includes when there's <stdlib>stlport property is simple. What is not
simple is automatic creating of lib target for stlport. The problem is that 
the module for handling stlport is not considered "project" and is not allowed
to declare target. Hopefully this will be changed soon.

Thanks,
Volodya