[QBS] RFC pkgconfig support

[Joerg Bornemann]

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?

---pkg-config-module-factory.qbs---
ModuleFactory {
     name: 'pkg-config'
     property var binary: 'pkg-config'

     createModule: {
         // Script that gets a module object.
         // Initially, only module.name is set.
         // The script can modify the module and returns it on success,
         // returns undefined otherwise.

         var p = new Process();
         if (p.start(binary, ['--exists', module.name]) != 0)
             return undefined;

         if (p.start(binary, ['-cflags']) != 0)
             return undefined;

         // Now we must create the module - dynamically in JS.
         addDependency(module, "cpp");
         module.cpp.cflags = p.readAll();
         // or even split the cflags into includePaths, libs etc.
         return module;
     }
}

What happens if more than one module factory can generate a module 
"foo"? Who wins? Do we add dependencies between module factories or 
priorities?

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


Jörg