[QBS] External modules

[Oswald Buddenhagen]

On Thu, Sep 06, 2012 at 05:26:13PM +0600, ext Ruslan Nigmatullin wrote:
> Firstly, to minimize size of sources we introduced CommonModule with such syntax:
> 
> CommonModule {
>     frameworkName: "qca"
>     pkgConfigName: "qca2"
>     libraryNames: ["qca", "qca2"]
>     includeNames: ["qca.h"]
>     includeSuffix: "QtCrypto"
> }
> 
> It looks ugly, but covers most of usecases. As you see module name ("qca") doesn't contain all needed information for package lookup as it's library/framework/pkg-config name may vary and differ from module's one. Internally CommonModule contains several Probe's (Framework, PkgConfig, Library, Include) so it's too hard to implement the same logic for _every_ small module.
> 
this goes into the direction i wanted.
there is clearly some pattern in it as well, so trivial modules could be
fully automated with a factory (though i'm not sure it really makes
sense - there may be too many exceptions, and then we'd just introduce
asymmetry).

> It doesn't change during one execution of program, so may be there
> should be an mechanism to cache some values? May be some way to write
> result to session-life container, which would be shared between all
> modules? Proposed syntaxes: [...]
> 
> Any ideas?
> 
the declarative approaches are preferable, as it's harder to get them
wrong for the user and it's easier to have a central approach to
resetting the cache (think qbs --recheck to discard all negative cached
results, and qbs --recheck-all to discard all cached results).

in fact, i was thinking of making *all* properties implicitly cached by
storing them (including all their dependencies, so change propagation is
fully automatic) in the state file (aka build graph). 
https://bugreports.qt-project.org/browse/QBS-7
also https://bugreports.qt-project.org/browse/QBS-24 and subtasks (you
may actually resolve some of them as Done, i think).