[QBS] RFC pkgconfig support

marius.storm-olsen at nokia.com marius.storm-olsen at nokia.com
Thu Feb 23 17:17:25 CET 2012


On 23/02/2012 09:38, Joerg Bornemann wrote:
> On 23/02/2012 13:09, ext marius.storm-olsen at nokia.com wrote:
>> The qbs user shouldn't have to think about a module being local or
>> not. Changing a project from using a system libpng to a
>> local/specialized version, should simply be to drop in a libpng
>> project with its own .qbs file somewhere in the project hierarchy.
>> No modifications to the other project should be needed.
>
> Allright. The user writes Depends { name: "foo" } into his project.
> The module "foo" cannot be found in any search path. Now we're asking
> all registered "module factories" to look for the "foo" module. The
> pkg-config module factory calls 'pkg-config --exists foo' to
> determine if it should generate a module or not. Then it dynamically
> generates the module "foo".
>
> So far so good. How could it look like?
>
...
>
> What happens if more than one module factory can generate a module
> "foo"? Who wins? Do we add dependencies between module factories or
> priorities?

For module factories I think the a specific one should win, with a 
property to allow/disallow fall-back to general ones if it couldn't find 
one.

// I have no idea here, assume pseudo code here :)
// This could be a qbs or project provided module
Module {
     name: 'qt'
     allowFactoryFallback: true

     findModule: {
         // do whatever to locate a module on any system..
         return module;  // if undef, ModuleFactory is used
     }
}

Theoretical example: a Qt.qbs one might focus its efforts on finding 
development versions of Qt4/5 to use, while if not found would then 
allow it to fall back to a more general module factory, such as the 
pkg-config one to find system installed ones. (Obviously the qt.qbs once 
would try to resolve any system installed one too, but just thinking 
about the concept here.)


> What about rules that can be part of a module? Do we want to be able
> to generate those dynamically as well?

"Rules that *can* be part of a module"? Generate module rules 
dynamically? Not sure I'm following you here. What do you mean?

-- 
.marius


More information about the Qbs mailing list