[QBS] A more general replacement for qbs-setup-xxx utilites

[Oswald Buddenhagen]

On Tue, Mar 31, 2015 at 11:39:14AM +0300, Aleksey Sidorov wrote:
> Some thoughts about qbs project configure:
> 
> 1. The configure results must be an artefacts that can be track by qbs
>
i'm not quite sure what you mean by that.

configure results are properties which are aggregated in modules.
properties are transparently cached in the state file ("build graph").
dependencies between properties are tracked, and (hopefully all)
functions which get information from outside the project (like getting a
file list) are included into this mechanism.

but then, it is necessary to specify invalidation criteria, as for
example a property which is set as the result of calling an external
process theoretically needs to be refreshed each time, which would be
inacceptably slow. the syntax could be this:

  property cached string compilerVersion;

on the command line, you'd have two invalidation levels (in addition to
the non-invalidating default): invalidate cached properties which are
undefined/false (this is the common case of "i installed missing
dependencies, now update your state"), and invalidate all cached
properties (for example when one upgraded a dependency to a
significantly different version).

> 2. Now there are products which are not compiled by default. It is
> used for example to run tests.Looks interesting but a little unusual.
>
we've been pondering adding some kind of subprojects which are compiled
only as part of a test, but at this time i don't think that really makes
a whole lot of sense. instead, one wants to dynamically construct an
isolated project from a bunch of parameters (a source code snippet,
already detected dependencies, etc. - just like in autoconf and cmake)
and invoke qbs on it recursively. of course, that can/should be
optimized internally to avoid actually calling a separate process, but
that's optional.

> May be need to introduce a new entity - command? They can do some
> actions with the products with concrete types. It is also support
> inheritance and dependencies. Also it would be nice to be able to set
> command line arguments for command
>
> 3. Add a special artefact which can create a property set using probes
> or another runtime operations. This operations can be invoked by
> "configure" command.
> 
did you actually read the threads i linked in their entirety?