Re: [jamboost] QT support, and some problems

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-18 21:01:19

Vladimir Prus <ghost_at_[hidden]> writes:

> I've just added preliminary QT support to CVS. I'm now able to
> cd to examples-v2/qt, run "bjam" there, and obtain an working
> QT application.
>
> Felix, can you check it out, first with gcc, and then with Kylix?
>
>
> However, this support has one *horrible* kluge. It directly adds "-lqt" to
> the linker command line. It is probably OK here, but in general it bring the 
> following two questions:
>
> 1. The right way with qt would be:
> 1. I say "using qt ; "

Or "configure qt ;" with the UI we decided to switch to.
It also could end up looking like:

configure qt : /path/to/qt/headers ;

> 2. The module "qt" declares a library target, and adds
> "<library>the-target" to properties of all main targets
> that use QT.
>
> Clean, but only Jamfile modules, which are created in a special
> way, are allowed to declare targets.

This item was supposed to be a question? I don't see one.

Why the restriction that only Jamfiles are allowed to declare targets?

> 2. I want to use my own parser generator, and to have it as part of
> build process. What I mean is: the generator is used for building
> my project, but if the sources for the generator change, it should
> be rebuild, together with all files in my project which it produces.

However, we should have a mechanism which prevents multiple variants
and toolsets from being used to build a build tool.

> No problem, it's possible to use other projects in Jamfile. However,
> other project wants to declare new target types and new generators and
> new features. It's not possible to allow that everywhere.

Why not? because of the possibility of a name conflict?

> (Other project can be referred from any Jamfile).

Yes.

> Did I explained the problems well enough? 

Nope.

> Looks like the first one is rather technical. We'd need to allow
> "qt.jam" to create fake project (i.e. not related to any Jamfile),
> and declare targets there.

That sounds like one good approach. We could also define some sort of
"global" project for this purpose.
>
> The second looks like a design question. Would it be acceptable if we
> say that project which declare features/types/generators can be referred
> only from project-root files. This way, we'd collect full set of features, 
> etc. before generating the first target.

I'm not sure I understand the issues here.

-Dave

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution