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

Aleksey Sidorov gorthauer87 at yandex.ru
Tue Mar 31 10:39:14 CEST 2015


Some thoughts about qbs project configure:

1. The configure results must be an artefacts that can be track by qbs
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.
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.

Possible syntax:

Command {
    name: "configure"
    productTypes: ["compile_check", "runtime_check"]
    
    ... unknown magic ?
    CommandLineOption {}
}

...

Command {
    name: "build"
    productTypes: ["application", "dynamiclibrary", ... ]
    
    Depends { name: "configure" }
}

Command {
    name: "run"
    productTypes: ["runnable"]
    
    Depends { name: "build" }
}

Command {
    name: "debug"
    productTypes: ["runnable"]
    
    Depends { name: "build" }
}

Command {
    name: "install"
    productTypes: ["installed_content"]
    
    Depends { name: "build" }
}

...
project.qbs

GenericProject {
    
    BuildCommand { ... }
    RunCommand { ... }
    InstallCommand { ... }
}
...

Command {
    name: "build"
    productTypes: ["application", "dynamiclibrary", ... ]
    
    Depends { name: "configure" }
}

Command {
    name: "run"
    productTypes: ["runnable"]
    
    Depends { name: "build" }
}

Command {
    name: "debug"
    productTypes: ["runnable"]
    
    Depends { name: "build" }
}

Command {
    name: "install"
    productTypes: ["installed_content"]
    
    Depends { name: "build" }
}


27.03.2015, 21:36, "Oswald Buddenhagen" <oswald.buddenhagen at theqtcompany.com>:
> On Wed, Mar 25, 2015 at 02:19:55PM +0300, Aleksey Sidorov wrote:
>>  I think, that had accumulated enough hard coded tools to setup qbs
>>  profile. And I think more complex applications will want more of these
>>  utilities.
>>
>>  May be need to replace qbs setup tools with qbs script based solution?
>
> i think i managed to convince joerg that you are right. :)
>
> the general idea is that all environment detection/adaptation should be
> in "configure" parts of the modules it affects.
> https://bugreports.qt.io/browse/QBS-24
>
> profiles should be very thin containers with:
> - environment variables
>   - the default profile would just inherit the current environment
> - a "dumb" set of module-specific properties of two kinds:
>   - additional parameters that help the configure probes:
>     - path to the compiler for the cpp (toolchain) module
>     - path to qmake for the qt module
>   - "selector" properties that help to decide which version of a module
>     to use if multiple equally suitable builds are found (the discussion
>     in https://bugreports.qt.io/browse/QBS-701 is pertinent. also,
>     https://bugreports.qt.io/browse/QBS-192 requires a solution to the
>     same problem at the project level)
>>  For example, some applications on unix wants to convert pkg
>>  config files to qbs modules or run some environment checks.
>
> http://lists.qt-project.org/pipermail/qbs/2012-February/000033.html
> http://lists.qt-project.org/pipermail/qbs/2012-September/000207.html
>
> there is a whole bunch of jira tasks with comments (mostly written by me
> :D) that concern configuration and use of modules, so you may want to
> familiarize yourself with qbs' jira task list in general.
>
> contributions in this area would be *very* welcome. ;)
>
> _______________________________________________
> QBS mailing list
> QBS at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs



More information about the Qbs mailing list