[QBS] Looking for libraries/include paths

[Oswald Buddenhagen]

On Mon, Aug 13, 2012 at 10:57:47PM +0600, ext Ruslan Nigmatullin wrote:
> But it's not IDE-friendly and it's easy to mistype.
> 
the ide-wise atomic entity is the module. how the module manages to set
up its properties is only the module definition's concern.

but you need to provide some facilities/libraries to make the module
definitions uniformly configurable from the outside, i.e., some global
paths for includes/libraries/pkgconfig/etc., and a standardized way to
override a particular module's prefix/include/library/etc. search path.

> Lookup classes should populate properties of "cpp" module
> automatically or manually, 
>
wrong way around. each module has a defined set of properties, and "cpp"
pulls them out as it sees fit.
so, the key is that the config test results must somehow end up in those
standard properties.

both of your approaches are functional: in the first one you'd make
bindings of the module's properties to function calls, in the second
you'd bind to properties of those lookup nodes.

the downside of the functional approach is that it's almost impossible
to efficiently bind it to the imperative outside world of the configure
tests (e.g., calling an external tool which produces results which need
to be distributed among several properties).

therefore our idea was to have configure nodes with imperative
constructor functions. this gives unlimited flexibility. i think it
would look more or less like this:

ConfigureNode {

  # input property. this is fully resolved before running the
  # constructor. the constructor can use only these input properties,
  # which equates to explicitly specifying all dependencies.
  # the alternative would be allowing resolving property bindings from
  # within the constructor. i don't know whether this is a problem as
  # such, but it would mean that it would be possible to invoke another
  # configure node in the middle, which could mess up some progress
  # information (think "Checking for myheader...Checking for
  # theirheader...found\nfound\n").
  property includeSearchPath: qbs.incudeSearchPath

  # output property. the first access to any such property causes the
  # constructor to be run.
  property includePath

  function Constructor() {
    for (var i in includeSearchPath) {
      if (exists(i + "/myheader.h") {
        includePath = i
	break
      }
    }
  }
}

this means that functions need to be available for at least the
low-level stuff, which automatically covers your first proposal.

but of course it would be still possible to write the majority of a
module definition in a functional way and resort to configure nodes only
in special cases. this also leaves room for providing lookup classes as
wrappers for those low-level functions. whether it's really worth it
needs to be found experimentally (i.e., don't do it until things start
to look ugly).

and also see
http://lists.qt-project.org/pipermail/qbs/2012-February/000034.html