[QBS] RFC pkgconfig support

[Joerg Bornemann]

On 23/02/2012 17:19, ext Ruslan Nigmatullin wrote:

> May be we should use more declarative way? So the rules won't be a problem anyway

Yeah a more delarative approach would save us from having two ways to 
specify modules. :)
How about the following? Scripting part and declarative part is 
separated and the context of the "module template" is clearly defined.

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

     ModuleTemplate {
         name: context.name
         Depends { name: "cpp" }
         cpp.cflags: context.cflags

         Rule {
             // transform this to that
         }
     }

     createModuleContext: {
         // Script that creates a module context object,
         // which is used in the ModuleTemplate above.
         // Returns a valid context object, if the module can
         // be created; undefined otherwise.

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

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

         var context = {};
         context.name = module.name;
         context.cflags = p.readAll();
         // or even split the cflags into includePaths, libs etc.
         return context;
     }
}

> Because all factories should provide similar module's data (If we want to build with system library usually there exists only one system library), simple priorities should be enough.
> But what will be unique names for this modules? As it was said above pkgconfig's packages' names are not the same as qbs' one. The same situation will be possibly presented for any other tools and archives, like ruby's gems. So there should be presented some converter for them.

I don't get the "all factories should provide similar module's data" part.

> More interesting is the situation when interested library is not found at all. Would be there any way to write workarounds around it if user wants to make application still be possible to build?
>
> Depends { name: "gstreamer"; relaxed: true }
> Group {
> 	condition: gstreamer.found
> 	files: [ "gstreamerbasedimpl.h", "gstreamerbasedimpl.cpp" ]
> 	cpp.defines: [ "HAVE_GSTREAMER" ]
> }
>
> Or even add to build new products (i.e. plugins) only in case if library is installed in system

Kind of, yes. This is a step on the way to have configure probes.


Jörg