From: Jürgen Hunold (hunold+lists.Boost_at_[hidden])
Date: 2003-09-18 03:52:35
-----BEGIN PGP SIGNED MESSAGE-----
Hi Volodya !
I'm just trying to get my programs to be built with msvc-7.1.
I've encountered several problems with qt.jam.
I've prepared a simple test case (attached) with some sample output
(file qtlib/compile.txt). In the top-level Jamfile I've setup
dependencies on Boost and Qt-libraries, too.
This test case models our general project setup.
Containing a lib and app folder, each containing different libs and
apps. For now, I've just one app depending on one library.
This setup and the current implementation of qt.jam lead to several
First, to get uic and moc support, I have to add <library>/qt to the
project requirements. This means each library is linked to the Qt
library (see compile.txt). This does not work for msvc.jam because the
link-action does add /lLIBPATH option to the linker. Even if it would
(I patched qt.jam to return the full path of the Qt-library), this
results in linker warning when linking the application with msvc,
because the Qt-symbols are already resolved when linking the library.
In production code, I've got several of these sub-libraries and hundreds
of unneeded warnings. It would be great, if the Qt library could only
be used when linking application targets.
Second, using dynamic Qt Library with msvc.
For this to work, you have to define QT_DLL globally.
This is missing right now.
And Trolltech adds the library version to the dll-basename.
This means for Qt-3.2.1, you get qt-312.dll for single threaded and
qt-mt321.dll for multithreaded library.
Is the an easy way to deduce this from the library path ?
That means, I just specify using qt : /usr/local/gcc-3.3.1/qt-3.2.1 and
bjam figures out the rest ?
Third, generated include paths.
This is a real show stopper. I tried to compile RailSys with msvc and it
stops due to command line overflow. This is due to the fact that the
generated include paths of some 30 libraries appear on the commandline
for the main() routine and bjam (cl.exe) chokes on this...
What I need is the following: Each library/exe should only its use its
own generated includes.
And I need to explicitly include generated include path from child and
sister-projects. Without this feature, my test case would not work,
because I have to add generated include path for lib/gui to app in
order to #include "hello_world_widget.h" in main.cpp.
I think this all I qt-related stuff I found while playing around with
bjam on win32 and linux.
I've found several other problems, but will report them in other emails
in order to keep things separated.
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
-----END PGP SIGNATURE-----
--Boundary-00=_TJXa/edPRACmyQt Content-Type: application/x-tgz;
[Attachment content not displayed.] --Boundary-00=_TJXa/edPRACmyQt Content-Type: text/plain;
# Copyright (c) 2002 Institute of Transport,
# Railway Construction and Operation,
# University of Hanover, Germany
# 02/21/02! Jürgen Hunold
# $Id: Jamfile,v 1.2 2002/01/31 10:46:56 hunold Exp $
local BOOST_ROOT = [ modules.peek : BOOST_ROOT ] ;
use-project /boost : $(BOOST_ROOT)/../boost-v2 ;
: build-dir ../../build
build-project qtlib ;
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk