Re: [jamboost] QT support, and some problems

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 04:43:36

David Abrahams wrote:
> 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 ;

It's already possible to specify the installation prefix.

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

Because targets now must be associated with some project. And projects are
only created when Jamfiles are loaded. We could either allow to make project
of any module, or create "standalone" targets, not associated to any project.
But it not yet possible.

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

True.

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

This is the minor problem. The biggest one is: you've called 'generate' on
top-level project, and when generating a target three levels deeper, target 
from another project is referenced. You load that project and its project 
root, which declares new features and new generators.

If those features and generators were visible from the very start, then:
1. The features would be included in build request.
2. The generators might have being used for already built targets.

In fact, we're changing something which is very important for
generation process, in the middle of that project. If we don't protect
against it, the system will be brittle.

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

Which is another good approach. BTW, we need some "global project" anyway.
For example,

bjam unit-tests

should build global target "unit-tests", and not require that you define that 
target in every project.

- Volodya