Re: [Qbs] Qbs 1.15.0 released

[Joerg Bornemann]

On 1/3/20 7:08 AM, Alberto Mardegan wrote:

> with the advent of year 2020, we'll eventually need to update the
> copyright in the source code. 

There's no need to do that. Qt itself stopped updating the Copyright 
year quite a while ago.

> Can you please clarify what is the
> situation, now that (unless I'm mistaken) The Qt Company won't be owning
> the project anymore?

Nothing changes wrt copyright.
Contributors can of course add their copyright to the files they touch, 
and we have several instances of non-Qt copyright statements.


Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Joerg Bornemann]

On 5/14/19 12:04 PM, Christian Gagneraud wrote:
> On Tue, 14 May 2019 at 22:02, Joerg Bornemann  wrote:
>>
>> On 5/14/19 10:57 AM, Tobias Hunger wrote:
>>
>>> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is 
>>> linked
>>> into Creator, that will also need to be ported to Qt 6 to stay feasible.
>>
>> ...which shouldn't pose a challenge at all given that Qt 6 is to keep
>> source incompatible changes minimal.
> 
> Unless they drop QtScript...

This is bound to happen anyway. It can be forked.


BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Joerg Bornemann]

On 5/14/19 10:57 AM, Tobias Hunger wrote:

> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is linked
> into Creator, that will also need to be ported to Qt 6 to stay feasible.

...which shouldn't pose a challenge at all given that Qt 6 is to keep 
source incompatible changes minimal.


Joerg
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] qbs 1.12 released

[Joerg Bornemann]

On 07/19/2018 05:39 PM, Christian Kandeler wrote:


we have released qbs 1.12 today. Find all the relevant information in
the blog post at
http://blog.qt.io/blog/2018/07/19/qbs-1-12-released/.


Packages for chocolatey, macports and homebrew have been updated in the 
meantime.



Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Clang and linking C++ on Windows

[Joerg Bornemann]

On 05/01/2018 10:00 PM, resurrect...@centrum.cz wrote:

What should be done in my 
opinion is to add windows-clang.qbs file similar to existing 
windows-msvc.qbs and windows-mingw.qbs in cpp module. And of course the 
profile routing would need to be changed so that Clang on Windows does 
not automatically mean everything GCC and Linux-like. I suppose the 
existing windows specific qbs files could be re-used.


That's pretty much what is needed to support clang on Windows.
The windows-clang cpp module would need to act like gcc for the compiler 
and like msvc for the linker.
The lion's share of the logic is in gcc.js / msvc.js. The windows-clang 
cpp module would import both and use the appropriate functions for 
compiler/linker.



BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Unable to run qdoc in Qt 5.11

[Joerg Bornemann]

On 03/24/2018 04:38 PM, resurrect...@centrum.cz wrote:

2. All header files need to be included in a "moduleheader" file 
specified in qdocconf file like so:


moduleheader = MyModule.h


I've now looked into this a bit more, and turns out that this is merely 
a warning, which can be ignored. If you really want to get rid of it you 
can set the environment variable QT_INSTALL_DOCS to 
here_is_my_Qt_installed/doc.



Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] qbs 1.11 released

[Joerg Bornemann]

Hello,

we have released qbs 1.11 today. Find all the relevant information in
the blog post at https://blog.qt.io/blog/2018/03/28/qbs-1-11-released/.


Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Unable to run qdoc in Qt 5.11

[Joerg Bornemann]

On 03/24/2018 04:38 PM, resurrect...@centrum.cz wrote:

Since the includepaths are not something you may wish to be setting 
manually in the *.qdocconf would it be possible to have a variable in 
which they may be set from Qbs file? Either that or more generically 
allow us to append additional command line arguments to qbs for invoking 
qdoc. I tried hacking into qt.core.qdocName but it did not do anything 
(probably read-only?).


You can possibly can use
Qt.core.qdocEnvironment: ["INCLUDE=/here/are/my/include/files"]
to specify the include path via an environment variable and then pick it 
up in the .qdocconf file with

   includepaths = $INCLUDE


BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Why is there Rule:alwaysRun but not Probe:alwaysRun?

[Joerg Bornemann]

On 10/17/2017 02:55 PM, NIkolai Marchenko wrote:

Both run arbitary scripts to do their work. QBS cannot assume that one 
script is better or more expensive than the other since both are 
arbitary and external to build system. So why defend the policy of not 
allowing alwaysSrun for Probes ? This makes no sense to me


Could you sketch a use case for probes that always run, please?


Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Second rule reads empty file generated by first rule

[Joerg Bornemann]

On 10/11/2017 07:11 PM, Denis Shienkov wrote:


I have a project with some rules: 'producer' and 'consumer',

The 'producer' generates an artifact with the JSON file, and the 
'consumer' receive this artifact on input and does trying to read 
content of this JSON file.


BUT: The consumer always reads an empty content, even the file exists 
and is not empty.


The reason might be: You don't call close() on the TextFile you're writing.


BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Depending on item with dynamic name

[Joerg Bornemann]

On 10/12/2017 08:26 AM, resurrect...@centrum.cz wrote:

is there a way do depend on a product with dynamically generated name? 
Via id prehaps or some other identifier?


E.g.:

/import qbs/

/import qbs.FileInfo/

/Project/
/{/
/    Product/
/    {/
/        name: FileInfo.baseName(sourceDirectory)/
/    }/
/    Product/
/    {/
/        Depends { name: "???" }/
/    }/
/}/

Is there a way to depend on the first product in the second one?


Note the following in the docs for Product.name: "The value of this 
property must be a simple JavaScript expression that does not depend on 
module properties or values that are non-local to this product."


The following works though:

Project {
property string theName: FileInfo.fileName(path)
Product {
name: project.theName
...
}
Product {
Depends { name: project.theName }
...
}
}

Christian, do we want to claim this as supported?



Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Rule with merging of inputs tuples (pairs)

[Joerg Bornemann]

On 10/11/2017 10:38 AM, Denis Shienkov wrote:
[...]

I have created a Rule:

Rule{
inputs:["a_binary","b_binary"]
Artifact{
fileTags:["c_binary"]
filePath:"c.bin";
}

[...]

}


but is is unclear how to define an output artifact's file pach, because 
it should be different

for each input, e.g. should be c1.bin, c2.bin and so on.?


IIUC you want the rule to be run once on the whole set of inputs. That's 
what we call a multiplex rule. Write


Rule {
multiplex: true
...
}

And you can operate on all a_binary and b_binary artifacts in your product.


BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] pre-built products (cont.)

[Joerg Bornemann]

On 24/09/2017 13:53, Christian Gagneraud wrote:

[...]

and so on. Or you cram all platforms into one file - as you like.

We should have a documentation page covering this use case. I've created
QBS-1191 for that.


Cool, but what (should) happen in case of several
$projectroot/modules/ThirdParty/lib1/*.qps matches?
Or none matches, for the matter?


Excellent question. If none matches, the module cannot be loaded. You 
will get an error message. If multiple files (module instances) match, 
then the current situation is that "the first one" wins. That means, it 
is currently important to keep the conditions mutually exclusive.


We got away with this non-design until now, but in 1.10 this will change 
to: multiple matching module instances are an error.
You will also be able to define an order for the instances by setting 
priorities. The matching instance with the highest priority is chosen. 
The exact formulation for the new behavior is: multiple matching module 
instances with the same priority are an error.


See QBS-61 and related patches for more information.


Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] pre-built products (cont.)

[Joerg Bornemann]

On 10/09/2017 03:44, Christian Gagneraud wrote:


In my source tree I have pre-built binaries, these are third-party
library that we get in binary form only. (PS: don't tell me that it is
bad, i already know that. I cannot change that, i have to deal with
it)


Even if it's bad we cannot ignore this situation. Some hardware vendors 
only provide binary libraries to talk to their devices.


[...]


So I would like to have a product for each of these, that would export
a include path, a lib search path and a lib name.
But of course i don't want these product to be built, because i don't
have the source code.

The reason i'm thinking about using the product item is that i can
then simply add references to the dependings product.

Is it the right approach?


While this works, you don't need to use a product. A module would be 
more "natural". Effectively, the Export item you're writing already 
defines a module with the same name as the product.



Maybe i should come with a Module approach, eg, something similar to
Qt itself, that would allow me to add:

Depends {
name: "ThirdParty"
submodules: [
   "lib1", "lib2", ...
]
}

I never tried that, not sure how to get started...


You would create a folder structure like this

$projectroot/modules/ThirdParty/lib1
$projectroot/modules/ThirdParty/lib2

and create $projectroot/modules/ThirdParty/lib1/x86.qbs
$projectroot/modules/ThirdParty/lib1/x86_64.qbs

with the content

---x86.qbs---
Module {
condition: qbs.architecture === "x86"
Depends { name: "cpp" }
cpp.dynamicLibraries: ["somewhere/x86/lib1.lib"]
}
---

---x86_64.qbs---
Module {
condition: qbs.architecture === "x86_64"
Depends { name: "cpp" }
cpp.dynamicLibraries: ["somewhere/x86_64/lib1.lib"]
}
---

and so on. Or you cram all platforms into one file - as you like.

We should have a documentation page covering this use case. I've created 
QBS-1191 for that.




Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Relation between Product and Export

[Joerg Bornemann]

Hi Michael,

indeed, at the moment you have to repeat the Depends items of the 
product in the Export item. This way you can clearly specify what the 
product needs and what users of the product need.


You're right that this looks a bit redundant, and there are thoughts on 
fixing this in QBS-584.



BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] qbs 1.8.1 tools/version.h not installed?

[Joerg Bornemann]

On 09/07/2017 17:19, Andrzej Telszewski wrote:


It looks like indeed "tools/version.h" should be installed.
After installing it:

...

Qt Creator builds fine.


Thanks for pointing this out!
This is fixed by https://codereview.qt-project.org/#/c/199668/


Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Qbs Automatic Projects

[Joerg Bornemann]

On 26/06/2017 10:44, resurrect...@centrum.cz wrote:

[...]
I tried Qbs and immediately recognised it had even bigger 
potential for automating project definitions except... it discourages 
doing that (see for example this 
 and quite a few other 
instances where such approach is discouraged). I honestly do not 
understand why. What does it bring me to type out the same thing over 
and over again? You would not do it in your code. You would make a 
method or class or at least a loop. Yet for some reason I am supposed to 
do that with project files...


Be assured that nobody want to discourage you from doing anything. If 
you have any specific use case in mind, please comment on the bug reports.


We are reluctant though to implement heaps of special features that are 
useful for only one person. That's how qmake became what it is today.



Model scenario

[...]
That's an impressive showcase containing some interesting ideas!
If that's really flexible enough for all kinds of projects is 
questionable though.



Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Reducing clazy noise

[Joerg Bornemann]

On 23/04/2017 17:52, Elyzabeth von Reuenthal wrote:

[...]

This however produces warning for both my code, and Qt headers. To fix this,
the readme says:

If you want to suppress warnings from headers of Qt or 3rd party code,
include them with -isystem instead of -I.


How can I achieve this with qbs?


Unfortunately there's no single switch for that. You can however modify 
your Qt profile like this:


Note the profile you're currently using, or use "qbs config 
defaultProfile" to find out what the default profile is.


Find the profile's search path:

$ qbs config --list profiles.qt562.preferences
profiles.qt562.preferences.qbsSearchPaths: 
"/home/someone/.config/QtProject/qbs/1.9.0/profiles/qt562"


Replace cpp.includePaths with cpp.systemIncludePaths in the Qt modules 
of that profile:


$ find 
/home/someone/.config/QtProject/qbs/1.9.0/profiles/qt562/modules/Qt/ 
-name '*.qbs' | xargs -n1 sed -i s/cpp\.includePaths/cpp.systemIncludePaths/


Afterwards, all Qt include paths for this profile are passed via 
-isystem to the compiler.



BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] FYI: Branch 1.8 created

[Joerg Bornemann]

Hi,

We have created the branch for the 1.8 release of qbs (ETA May 9th) today.

Contributors should push bug fixes and low-risk improvements to this 
branch; other changes should target the master branch.


Users are encouraged to test this branch against their projects, so 
possible bugs are found in time for the release.



BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[QBS] qbs 1.4.5 released

[Joerg Bornemann]

Hi,

qbs 1.4.5 was released today. This is a patch release that fixes a 
couple of bugs uncovered since the previous release. It is also part of 
Qt Creator 3.6.1, which was released today as well.
Source packages and a binary package for Windows can be downloaded from 
https://download.qt.io/official_releases/qbs/1.4.5/



Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Is that possible to getting qbs to running with NodeJS?

[Joerg Bornemann]

On 28-Oct-15 12:26, 罗勇刚(Yonggang Luo)  wrote:


Cause qbs is implemented with qml, and qml might be parsed and run
with Javascript.
So maybe we just need a node.exe along with a bunch of Javascript/qml files?


Sure, you can reimplement qbs in any language.
Just what's the advantage and who's going to write this "bunch of JS/QML 
files"?



BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Append to cpp.systemIncludePaths

[Joerg Bornemann]

On 01-Oct-15 13:47, Catalin Moldovan wrote:

You could do something like this:

---snip---
property stringList myDefaultDefines: [ "bx/include", "bgfx/include" ]
cpp.includePaths: myDefaultDefines

Properties {
 condition: qbs.toolchain.contains("msvc")
 cpp.systemIncludePaths: 
myDefaultDefines.concat("bx/include/compat/msvc")
}

Properties {
 condition: qbs.targetOS.contains("mingw")
 cpp.systemIncludePaths: 
myDefaultDefines.concat("bx/include/compat/mingw")
}
---snap---


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Using qbs for in-source build

[Joerg Bornemann]

On 04-Aug-15 22:14, Orgad Shaneh wrote:

>   * If I delete the output file it is not regenerated (unless I delete
> the build graph, which regenerates all the files)

The timestamps are stored in the build graph for performance reasons 
(esp. for Windows). If you mess around with the contents of the build 
dir you must pass --check-timestamps to qbs.

>   * If the source file is modified, but the target file has a newer date
> (e.g. pbuilder was invoked from the shell), it is still regenerated.

Probably because the target file path in your output artifact is never 
generated. You said pbuilder will generate files in the source dir.
You could add a rule "html" -> "html-copy" that copies each HTML file 
into the build dir. Then a rule "html-copy" -> "html-cpp" runs pbuilder 
in the build dir where the cpp files will end up.

>   * In my example, I simplified the generator's output. The generator
> actually produces 2 files: input.c and input_v.cpp. After it
> finishes, I need to rename input.c -> input.cpp (overwriting the
> existing one), and delete input_v.cpp.

You can use a JavaScriptCommand for that in the "html-copy" -> 
"html-cpp" rule.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] strange behaviour with cpp.linkerFlags

[Joerg Bornemann]

On 18-Jul-15 14:53, Stephan Gatzka wrote:

> I've seen a change between qbs 1.3.4 and 1.4.1.
>
> With version 1.3.4 I could specifiy
> cpp.linkerFlags: ["-u","read","-u","write"]
> expanding to
> -u read -u write
> when gcc is called for linking.
>
> With version 1.4.1 the same line expands to
> -u read write
> which is obviously not working.
>
> Did I specified it incorrectly or have I found a bug?

I believe this is the same bug that was reported some days before: 
http://lists.qt-project.org/pipermail/qbs/2015-July/001355.html

This is resolved for 1.4.2.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Unpacking an archive

[Joerg Bornemann]

On 12-May-15 12:22, Lars Ivar Igesund wrote:

> in a bid to build some additional 3rdparty libraries, I need to unpack
> an archive that contains some headers and some libraries.
>
> The unpacking part is easy enough, but I'd like to build the
> outputArtifacts list based on listing the stuff in the archive. Still
> possible, but how can I now generate the outputFileTags? First is that
> it would be better to generate this list together with the artifact
> list, and second I would want to query qbs for tags that it knows (e.g.
> header files or .so files).

Currently, outputFileTags is assumed to be a static list. You can fill 
it with everything your rule might produce. In your case it could look 
like ["hpp", "dynamiclibrary", "staticlibrary"].

There's no API yet for accessing the known file tags provided by file 
taggers. You might want to add a suggestion in the bug tracker.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Directive "import qbs". Whether it is necessary to define a version?

[Joerg Bornemann]

On 16-May-15 12:25, Карелин Павел wrote:

> Almost always qbs-scripts is beginning from a directive "import qbs". In
> some scripts, the version is assigned ("import qbs 1.0"), but in others
> - is no ("import qbs").
> In what cases, is need to specify the version?

Currently there is no difference between "import qbs" and "import qbs 
1.0". You can omit the version number for now.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Default install prefix

[Joerg Bornemann]

On 04-May-15 14:54, Joerg Bornemann wrote:

>> I recently installed QBS from sources, and to my (bad) surprise i got it
>> installed in /, instead of the more usual /usr/install (speaking about
>> Linux obviously). The reason for this is that I didn't configure/use any
>> prefix and/or destdir (autoconf semantic). Is it a QBS feature or is it
>> a QBS own source feature?
>
> Ouch! That's a bug in the qmake project files for qbs.
> You can control the install location by setting QBS_INSTALL_PREFIX:
>   qmake QBS_INSTALL_PREFIX=/some/where

This is now fixed for 1.4.1.
The default of QBS_INSTALL_PREFIX is /usr/local.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Default install prefix

[Joerg Bornemann]

On 01-May-15 02:04, Christian Gagneraud wrote:

> I recently installed QBS from sources, and to my (bad) surprise i got it
> installed in /, instead of the more usual /usr/install (speaking about
> Linux obviously). The reason for this is that I didn't configure/use any
> prefix and/or destdir (autoconf semantic). Is it a QBS feature or is it
> a QBS own source feature?

Ouch! That's a bug in the qmake project files for qbs.
You can control the install location by setting QBS_INSTALL_PREFIX:
 qmake QBS_INSTALL_PREFIX=/some/where

Thanks for spotting this!


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qbs 1.4.0 is now available in MacPorts and Homebrew

[Joerg Bornemann]

On 28-Apr-15 07:14, Jake Petroules wrote:

> The latest version of Qbs (1.4.0) is now available in both MacPorts and 
> Homebrew! I'll be keeping it up to date as well, quickly following each 
> release of Qbs by the Qt Project.

Works like a charm. Thanks, Jake!


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Will print() work in Qt Creator for Windows soon?

[Joerg Bornemann]

On 14-Apr-15 13:25, Hristo Hristov wrote:
> Or console.log() for the same matter?

There's QBS-548 to track the status.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Wrong ld arguments depending on source files

[Joerg Bornemann]

On 04-Apr-15 10:39, Ilya Lyubimov wrote:

> I have a directory called crypto in my project. At the same time I
> want to link my product with crypto library. The problem is that
> linkerFlags function from gcc.js looks for file with library name and
> having found crypto directory (I think it would be wrong behaviour
> even if crypto was a regular file) it doesn't pass "-l" argument. So
> in this situation the only option is to pass linkerFlags manually.
> I think a possible solution for this issue would be to split
> staticLibraries and dynamicLibraries properties into properties for
> libraries by name and properties for libraries by path, or use ":"
> prefix, as ld with "-l" argument do, for passing libraries by path.

How would those pairs of properties be called?

Why is "crypto" found by ld anyways? Did you add the project directory 
to the linker's search path?

> And another question is about linking static libraries. As far as I
> can see in source code there is no any difference between
> staticLibraries and dynamicLibraries properties. When I use
> staticLibraries property, I want to be sure that it will at least
> prefer static libraries or won't link dynamic libraries at all. But
> "-l" option of ld by default prefer dynamic libraries to static ones.
> May be it's better to link static libraries like this
> ""-Wl,--push-state,-Bstatic -lcrypto -Wl,--pop-state", to be sure that
> static version of library was linked.

That looks like a good idea at the first glance. We must make sure that 
every flavor of ld supports those flags though.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Using Assembler files with Visual Studio/MinGW on Windows

[Joerg Bornemann]

On 06-Apr-15 13:20, Hristo Hristov wrote:

> I added an assembler file to my project on Linux and it compiles and
> runs as expected.
> On Windows the assembler file appears to be ignored with Visual Studio
> and won't link with MinGW.
> Does Qbs support assembler files?

Yes, but apparently we forgot to add a rule for Visual Studio.
I've created QBS-775 for that.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Status of QBS w.r.t. deprecation of QtScript

[Joerg Bornemann]

On 25-Mar-15 22:56, Ruslan Nigmatullin wrote:

> Looks like right now it's impossible to migrate to QtQml without using 
> private API, i.e. QtQml doesn't provide any alternatives for QScriptContext, 
> QScriptEngine::newFunction and QScriptClass.

This is unfortunately true. Some features are just missing from 
QJSEngine and friends. I've created QTBUG-45246 for the missing 
QJSEngine::newFunction and QTBUG-45248 for the missing QScriptClass 
functionality.
IMO, the first one is a must-have for QJSEngine. That feature is 
definitely useful for a lot of people. The latter might be an edge case 
- I could live with depending on private API for that.

> So the question - should we force adding this public APIs to QtQml or start 
> using private API to make port? May be I'm missing something and there are 
> other alternatives?

There are holes in the API. We could fill those with our own 
implementations in qbs. Ideally, they can then be ported to QtQml and be 
part of the public API eventually.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Looking for a QMAKE_SUBSTITUTES equivalent

[Joerg Bornemann]

On 25-Mar-15 12:47, Benjamin TERRIER wrote:

> I am looking for an equivalent to QMAKE_SUBSTITUTES in qbs.

There's no such feature built into qbs.
For Qt Creator there's a qbs module that converts foo.plugin.json.in 
files to foo.plugin.json and replaces a fixed set of variables.
You can find the code in Qt Creator's repository in 
qbs/modules/pluginjson/pluginjson.qbs


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

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

[Joerg Bornemann]

On 25-Mar-15 12:19, 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. For 
> example, some applications on unix wants to convert pkg config files to qbs 
> modules or run some environment checks.
>
> May be need to replace qbs setup tools with qbs script based solution?
[...]

You're not talking about the setup-toolchain tool, right?
I don't see how it could be replaced by a generic facility.

As for the setup-qt tool, ideally the modules would be generated by Qt's 
configure step, and not by a qbs tool.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Status of QBS w.r.t. deprecation of QtScript

[Joerg Bornemann]

Hi Bill,

> I wonder, therefore, what the position of QBS within Qt is, when a
> module that QBS depends on is being deprecated in Qt!

QtScript is going to be deprecated, but it will keep working for quite 
some time.

Sooner or later qbs must be ported to the QJS* API of the QtQml module 
anyway. The deprecation of QtScript is yet another motivation point to 
do that.

Note that the 1.3 branch of qbs still had to build with Qt4. Qbs 1.4 is 
the first version where such a port would make sense.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qt Plugin with QBS

[Joerg Bornemann]

On 16-Mar-15 13:12, at-2500 wrote:

> I am trying to set up a project using the Qt Plugin System.

The basic setup to create a Qt plugin is
   - create a product of type "dynamiclibrary"
   - add a JSON file and tag it with "qt_plugin_metadata"

> The project consists of multiple binaries, one dynamic library that defines 
> the Q_INTERFACE (LIB) and multiple plugins (PLUGIN) implementing this 
> interface. To have common unit tests for all plugins, I have a gtest-based 
> binary that loads and tests the plugins via their interface. This binary 
> should only get linked to LIB, not to PLUGINS, which is why I removed the 
> „dynamiclibrary“ tag, and added a new tag, „plugin“ for PLUGINS. Now, of 
> course, my plugin will not be build because there is no rule cpp,hpp - 
> plugin. Is there an easy way to call the prepare script of the cpp rules that 
> would be active for a dynamic library? Something like prepare: 
> cpp.compiler.prepare? Or is there a better way to achieve what I want?

This use case is independent from Qt plugins.
Unfortunately there's currently not a good way to call the compiler's 
prepare script again. See also QBS-5.

What you can do instead is something like this

DynamicLibrary {
 name: "PLUGIN1"
 Depends {name: „cpp“}
 Depends {name: „LIB“}
 files: [...all cpp files for building the plugin...]
}

Product {
 name: "PLUGIN1_LINK"
 type: ["plugin_link"]
 Depends {name: „PLUGIN1“}
 // Rule to create the symlink for a plugin.
 // Use inheritance to avoid code duplication.
}

And then let plugintester depend on the PLUGIN*_LINK products.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qt Quick Compiler with QBS

[Joerg Bornemann]

On 13-Feb-15 15:01, olivier musse wrote:

> Thanks, it seems you know Qt Quick Compiler better than I  ;o)
> So when do you think the magic part can be added to QBS ?

I've added an example to QBS-749 that demonstrates how to use the 
qmlcompiler with qbs 1.3. The magic is done in CompiledQmlApp.qbs. The 
actual app project looks like this

---snip---
import qbs

CompiledQmlApp {
 name: "MyApp"
 files: ["main.cpp"]
 qmlResourceFiles: ["qml.qrc"]
}
---snap---

Build the project with qbs -f myapp.qbs and make sure that your Qt build 
has the QML compiler installed.



BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qt Quick Compiler with QBS

[Joerg Bornemann]

On 13-Feb-15 13:15, olivier musse wrote:

> Many thanks for adding this feature request.
> Since QtQuickCompiler is a compiler which seems to work by transforming
> qml files into cpp files, perhaps it can be handled without any
> development in QBS but just by using Rules.
> qiquickcompiler.exe is a command line tool so it should be possible but
> since when using a pro file, everything is hidden on how it works, we do
> not have any idea on how to call it.

It's possible to add qtquickcompiler support without modifying qbs. But 
adding a rule is not enough. When you write CONFIG+=quickcompiler the 
following magic happens:

All qrc files in RESOURCES are scanned.
If foo.qrc contains .js or .qml files, then it is removed from RESOURCES 
and passed to the qtquickcompiler instead.
If foo.qrc contains additionally files that are not .js or .qml, then 
those files are added to a newly generated .qrc file.
So all QML .qrc files are passed to the qtquickcompiler, the non-QML 
.qrc files are passed to rcc. Additionally, loader code is generated 
(qtquickcompiler_loader.cpp).

> Since we are commercial users, we may ask information to the QtCompany
> Support team on how call must be made. Do you think it can help?

I cannot make promises on behalf of our support team. But you can always 
ask them. :)


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qt Quick Compiler with QBS

[Joerg Bornemann]

On 12-Feb-15 16:20, Jicquel Dorian wrote:

> I would like to know if it is possible to use the qt quick compiler with
> qbs , i searched in the documentation that mentionned it could be used
> qith qmake/cmake but no mention of qbs.

Apparently nobody tried yet. I've created 
https://bugreports.qt.io/browse/QBS-749 to track this issue.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Export object files instead of static library

[Joerg Bornemann]

On 12-Jan-15 11:47, Andrey Anpilogov wrote:
>  > "those symbols are marked as "weak" but still exist in a static
> library, right?"
> They do. But they will not be linked because of priority.
> So I have program.c with:
> void "weak" foo() {};
>
> and target.c:
> void foo() {do_something();}
>
> If I link them together into static library and link with ELF file then
> "weak" foo() is going to be executed.
>
> The only one way to workaround it is link program.c.o and target.c.o as
> object to ELF file.

So you're defining a weak symbol S1 with name "foo" in your lib.
In your program that uses the lib you define S2, also with name "foo". 
S2 now overrides S1, because S1 is weak and S2 is strong. But you want 
to prevent the override by passing the object file with S1 as last 
argument to the linker.
Do I unstand correctly?


Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Define "Depends" programatically

[Joerg Bornemann]

On 12-Jan-15 11:53, Andrey Anpilogov wrote:

> I'm not sure what you mean by: "One could add some property like".
> Could you explain what is the idea?

The idea is to add a property as described.
This must be done in qbs. It's not possible in the current version.


Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Export object files instead of static library

[Joerg Bornemann]

On 12-Jan-15 04:44, Andrey Anpilogov wrote:

> One of the things I have no idea how to do is "weak" function in static
> library.
> I have one static library that builds as Product. It has couple files
> with "weak" functions:
> files:
> - somelib.cpp
> - extracool.cpp
> - base.c
> - weakfuncs.c
>
> Let's say base.c and wealfuncs.c have "weak" functions.
> Which means I have to link the application:
> main.cpp.o path_to_lib/somelib.a path_to_lib/base.c.o
> path_to_lib/weakfuncs.c.o

I'm not sure that I understand your case.
Why do you have to pass the object files to the linker?
If you're talking about weak symbols in ELF object files then those 
symbols are marked as "weak" but still exist in a static library, right?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Define "Depends" programatically

[Joerg Bornemann]

On 11-Jan-15 16:30, Andrey Anpilogov wrote:

> Is there any way to "call"/"define" Depends programatically?
> For example based of project property.

Due to the aim of creating a declarative project representation this is 
currently not possible.
One could add some property like

Product {
 dependencies: [{name: "cpp"}, {name: "foo"}, ...]
}

that is in essence a list if Depends items.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] what about path magic variable?

[Joerg Bornemann]

On 08-Jan-15 13:13, Smirnov Vladimir wrote:
>> Vladimir, you can use
>>
>> Export {
>>   ...
>>   cpp.includePaths: ["."]
>> }
>>
>> as a temporary workaround.
> I already widely use Export item, I didn't know that such use IS
> "workaround" (just thought it's normal).

That's not a work-around, but the way to go.
The example is bad and will be fixed.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] 'Large' projects with hierarchy

[Joerg Bornemann]

On 02-Jan-15 14:38, Marcel Mulder wrote:

[...]
>> I can also get this to compile by adding Depends { name: “cpp”} to the 
>> product but than it does not use my compiler setting which I need for my ARM 
>> cortex controller.
>> I few question raises:
>>
>> 1. Is there another way of dealing with defining the compile option in one 
>> qbs file and and define include paths and source files in another abs file?

You could use inheritance to define products with special properties.
Qt Creator or qbs itself are good examples for doing things like this.

>> 2. Is it an idea that if you depend on a product the files defined in the 
>> sub product are added the the files list of the product which depends on it? 
>> Just as the include path is added to the compile options.

Sounds like QBS-59.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to compile QBS without config_ui

[Joerg Bornemann]

On 27-Dec-14 20:53, Карелин Павел wrote:

> For compiling QBS I use Qt in minimal configuration (see
> http://bugreports.qt-project.org/browse/QBS-719). In this case the
> config-ui isn't compiled. For solution of the problem I use a patch:

 From the configure line of QBS-719 I can see that you're using Qt4.
There's no good way to determine if QtGui is available.
That's one of the reasons why Qt5 was modularized. Consider switching to 
Qt5 for building qbs.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Installing Visual Studio debug files (.pdb)

[Joerg Bornemann]

On 17-Nov-14 10:33, Christian Kandeler wrote:

>> What about changing the applicationLinker ruleto conditionally producea
>> debugFile artifact,depending on the current tool chain and the status of
>> thedebugInformation property?
>
> Sure, that would be the fix. qbs should be aware of all build artifacts,
> so I think this is just an oversight. You might want to file a bug report.

I've created QBS-713 for that.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What about generator APIs reviews?

[Joerg Bornemann]

Hi Vladimir,

> Since November, 12th, I don't see any activity on reviews  - Joerg,
> Christian, what's up?

Ah, I'm usually ignoring activity on WIP patches until I'm informed of 
their completion. That's all. We'll have a look.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What is the semantic difference between Rule and Transformer?

[Joerg Bornemann]

On 08-Nov-14 14:40, Smirnov Vladimir wrote:

> So I can imagine that Rule wraps some Transformer's functionality. But
> why don't just use only Rules? What can i do with Transformer that Rule
> couldn't cover?

Like Tim already mentioned, rules are triggered by matching file tags, 
transformers OTOH have file paths as input.
Rules can be seen as templates for transformers, or as a generalization.

The only thing you can't do with rules is producing artifacts out of 
thin air, like Stéphane wrote. But it would be possible to enable rules 
that have no input file tags. Shall we? :)

In qmake land transformers are similar to QMAKE_EXTRA_TARGETS and rules 
are like QMAKE_EXTRA_COMPILERS.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Is there are way to deploy *qm files?

[Joerg Bornemann]

On 06-Nov-14 13:44, Denis Shienkov wrote:

> How I can deploy a *.qm files together with the executable files?

You need to tell qbs that artifacts that are tagged as "qm" should be 
installed:

Group {
 fileTagsFilter: "qm"
 qbs.install: true
 qbs.installDir: "blabla"
}

See also http://qt-project.org/doc/qbs-1.3/group-item.html


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Specifying static runtime libraries with MSVC

[Joerg Bornemann]

On 29-Oct-14 09:12, Thomas Epting wrote:
>  > > Now I think of adding an appropriate option to Qbs.
>>
>  > There was already a bit of discussion going on in QBS-570.
>  > I'll add a comment there.
>
> Thank you. I've added another comment regarding MSVC.
>
> Here's my current test implementation (applied to Qbs 1.3):
[...]

Looks good so far. Care to upload it via gerrit, or shall we take over?
Unfortunately we can only accept patches that went through gerrit for 
legal reasons.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Specifying static runtime libraries with MSVC

[Joerg Bornemann]

On 28-Oct-14 08:57, Thomas Epting wrote:

> I'm trying to compile a project on Windows using static runtime
> libraries.
[...]
> Now I think of adding an appropriate option to Qbs. How would you name
> such an option? Does it make sense with other compilers, too, or is it
> needed for Microsoft compilers only?

There was already a bit of discussion going on in QBS-570.
I'll add a comment there.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] remove unwanted compiler flags

[Joerg Bornemann]

On 22-Oct-14 19:40, Railway Coder wrote:

> I use qbs for building my code for an embedded system.
> Compiler is set in Qt Creator as Kit for Bare Metal development.
>
> If I set compiler flags like this:
[...]
> I get unwanted flags in the output:
[...]

-pipe
is passed to gcc unconditionally. We assumed that every gcc can cope 
with it. Do we need an option to turn it off?

-fvisibility=default
can be turned off by setting cpp.visibility to undefined.

-x c++
should not be added if your source files have a standard C++ file 
extension. Which Qt Creator version is this?

-Wextra
is controllable via cpp.warningLevel

-Wl,--unresolved-symbols=ignore-in-shared-libs
is controllable via cpp.allowUnresolvedSymbols

-g
cpp.debugInformation: false

> How can I prevent qbs from adding flags which are not specified by me?

There is no "don't mess around with compiler flags" option.
Specify what you can with cpp properties, and only add things to 
cpp.cxxFlags if you really need to.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Do you use Qt4 to build qbs?

[Joerg Bornemann]

On 17-Oct-14 16:29, Orgad Shaneh wrote:

> He meant building Qbs itself, not the projects it builds...

Exactly. All is well. You will still be able to build your Qt4-based 
projects. :)


Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[QBS] Do you use Qt4 to build qbs?

[Joerg Bornemann]

Hi,

we're contemplating to drop support for building qbs with Qt4.
This will enable us to remove a tiny bit of legacy code, reduce the load 
on our test machines and - most importantly - use more Qt5 features, 
like QJSEngine etc.

If you have a strong argument why you need to build qbs with Qt4, please 
speak now, or forever hold your peace.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to link setargv.obj

[Joerg Bornemann]

On 01-Oct-14 17:59, Kurt Keller wrote:

> How is it possible, to link a windows console application against
> setargv.obj?

Try
 cpp.linkerFlags: ["setargv.obj"]
Most likely, you have to pass the absolute path to the object file.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How do I enumerate the properties of a qbs object?

[Joerg Bornemann]

On 29-Sep-14 07:51, Карелин Павел wrote:

 I would like to investigate properties and values of QBS objects.
 But usual javascript a design of enumeration didn't work:
 for (var p in project) {
  // Here never we get...
 }

I don't see a good reason why this shouldn't work.
But a quick test shows that this is indeed broken.
Do you care to create a bug report?


Thanks,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What is the suggested way to do deeply nested projects?

[Joerg Bornemann]

On 13-Aug-14 14:34, Alexandre Cossette-Pacheco wrote:

> So, project "company.product.some_module.submodule" is
> - Located in the "company/product/some_module/submodule" folder
> - With
> "company/product/some_module/submodule/company.product.some_module.submodule.qbs"
> as the full path to the qbs project name

That shouldn't be a problem. The directory structure reflects the module 
name. The file name isn't used for this.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What is the suggested way to do deeply nested projects?

[Joerg Bornemann]

On 13-Aug-14 11:36, Joerg Bornemann wrote:

> I currently do not see a nice way how to magically determine whether a
> dot in a name means "hierarchy separator" or "it's just a dot".

And after an office discussion we suddenly see a way on the horizon how 
this can be fixed. Keep track of QBS-665 and QBS-666.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What is the suggested way to do deeply nested projects?

[Joerg Bornemann]

On 12-Aug-14 15:07, Alexandre Cossette-Pacheco wrote:

[...]
> However, project names have stayed awkward to this day; both with Qmake
> and Qbs (our current build system is Qmake, but we maintain scripts that
> parse our .pro files and generate .qbs so we can track progress on Qbs).
> The best we've found yet is to use underscore in project names. But it
> becomes super awkward for some of our modules that already include
> underscores in their names (we end up with project
> "company_product_some_module_submodule"). It would be nice and natural
> of we could have project contain nice dots in there (or do you have a
> better separator than '_' to propose?). And yes, we do also have some
> .NET projects here and it is nice to follow similar naming conventions :).

The dot is supposed to reflect the directory structure of modules. 
That's why it's handled specially.
You can use any other character than the dot as separator.
Product.name doesn't have to be a valid JavaScript identifier.
So maybe use company-product-something-else or 
company::product::something::else.

And then maybe add a base item like
 ---MyProduct.qbs---
 Product {
targetName: String.replace(name, "::", ".")
 }
that automatically sets the targetName to a string with dots.

I currently do not see a nice way how to magically determine whether a 
dot in a name means "hierarchy separator" or "it's just a dot".

> Else, we're overall very happy about how Qbs is shaping up. It's a great
> step up for us from qmake, in terms of raw power of customizing our
> build process, in terms of performance and in terms of usability.

That's nice to read! :)


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] What is the suggested way to do deeply nested projects?

[Joerg Bornemann]

On 09-Aug-14 23:12, Erik Schilling wrote:

> Currently qbs does not allow DynamicLibraries with more than one ".".

That's not quite right. Creating dynamic libs with more than one "." in 
their targetName is definitely possible.

> Now what is the suggested way to build a structure like:
>
>  +"Toplevel"
>  +-+"SecondLevel"
>  | +--"ThirdLevel"
>  ...
>
> Toplevel.SecondLevel.ThirdLevel does not work since that has two "." and
> hence triggers the said error when mentioning it in a Depends {} tag.

Product.name is the identifier that's used for referencing the product 
in a Depends item. This one cannot contain more than one dot, and it 
shouldn't contain any dot, actually.
Use Product.targetName to set the base name of the produced dynamic lib.

DynamicLibrary {
 name : "one_two_three"
 targetName: "one.two.three"
}

Application {
 Depends { name : "one_two_three" }
 name: "myapp"
}


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Preserve directory structure during installation

[Joerg Bornemann]

On 07-Aug-14 18:14, Christian Kandeler wrote:
> On 08/07/2014 12:57 PM, Richard Weickelt wrote:
>> how can I install a specific file type from a given folder while preserving
>> the folder hierarchy?
>
> There currently is no good solution for the general case. We hope to
> solve this for qbs 1.5, where an overhaul of the approach to
> installation is planned anyway.

FWIW, that's QBS-651.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to resolve dependencies on generated header files

[Joerg Bornemann]

On 07-Aug-14 15:14, Richard Weickelt wrote:

> Eureka! Thank You for explaining. I think, my problem is located in the
> definition of 'dependency' which seems to have a rather temporal meaning.
> Let me repeat in my own words what You have said: If foo.cpp includes foo.h,
> QBS detects a *dependency* between them through its built-in cpp-scanner.
> Dependency means: if foo.h is generated by a rule, QBS ensures, that foo.h
> is generated *before* foo.cpp is compiled. It does *not* add the output
> folder of foo.h to the includePath of foo.cpp. The latter is what I have
> expected and where the confusion comes from.
>
> Is this correct?

That's correct. :)


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to resolve dependencies on generated header files

[Joerg Bornemann]

On 07-Aug-14 12:55, Richard Weickelt wrote:

> What 'automatically' means then in the above paragraph? Does it mean
> anything beyound "generated header files can be tagged and therefore serve
> as dependencies for other rules"?

If there's a foo.cpp that includes foo.h and foo.h is generated by such 
a dyamic rule then a dependency from foo.cpp to foo.h is added. If the 
rule decides in a later build that foo.h is not generated anymore, then 
foo.h (and the dependency) is removed.
That's basically what I tried to compress into the word "automatically".
No magic, maybe even not worth mentioning, but an important automatism.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to resolve dependencies on generated header files

[Joerg Bornemann]

On 07-Aug-14 11:45, Richard Weickelt wrote:

>> Qbs now supports rules with a flexible number of outputs.  For example,
>> you may write an IDL file containing the descriptions of several C++
>> interfaces. An interface compiler generates a number of header files. The
>> generated header files are automatically taken into account as potential
>> dependencies.
>
> I stumbled over the word *automatically*. I know how to write custom
> transformation rules in modules to generate header files, but I do not
> understand how the generated header files would magically appear in
> cpp.includePaths.

They don't appear magically in cpp.includePaths, and I have no clue how 
you've concluded this from the above paragraph.

> From what I understand, I would have to define an extra product for
> generated header files which anoher product can then depend on [1] or I
> could use a fixed output folder, where all generated files are written to.
> This output folder is then explicitly added to cpp.includePath. The latter
> is done for ui files in [2] as well.

That's true. What exactly is your question?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Global and local properties in projects and products

[Joerg Bornemann]

On 25-Jul-14 15:12, Richard Weickelt wrote:

> When building "myApplication", different configuration options come to my 
> mind:
> 1. Global properties with influence to every product inside "framework"
> and "app"

Project {
 ...
 property string somethingGlobal: "global"
 SubProject {
 filePath: "framework.qbs"
 inheritProperties: true// this is the default
 }
}

> 2. Local properties, only valid for "lib1" or "lib2"

Project {
 ...
 SubProject {
 filePath: "framework.qbs"
 Properties {
 somethingLocal: "changed from outside"
 }
 }
}

---framework.qbs---
Project {
 property string somethingLocal: "local"
}


See also http://qt-project.org/doc/qbs-1.2/subproject-item.html


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Qt ActiveX building

[Joerg Bornemann]

On 26-Jul-14 20:18, Denis Shienkov wrote:

> Does supports by the QBS  of building (compilation, generation of IDL
> file, linking, and so on, by analogy with QMake)
> for the Qt ActiveX projects?

Support for dumpcpp, idc and friends is still missing. There's QBS-337 
to track the progress for this.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Error message when conditionally using string lists on project level

[Joerg Bornemann]

On 12-Jun-14 12:14, Thomas Epting wrote:
>  > That's a bug. I've created QBS-613 for that and added a comment
>  > that shows a work-around.
>
> Thank you! Do you have any plans when this could be fixed?

There's now a link to the proposed fix in the issue.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Error message when conditionally using string lists on project level

[Joerg Bornemann]

On 12-Jun-14 09:42, Thomas Epting wrote:

> Any ideas?

That's a bug. I've created QBS-613 for that and added a comment that 
shows a work-around.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Using multiple toolchains in one build

[Joerg Bornemann]

On 04-Jun-14 16:33, johannes.mato...@microchip.com wrote:

> we have a project which generates a WiX-based installer for library. We
> now want to include binaries of this library for different MSVC-runtimes.
>
> I want to avoid using external scripts for starting the different builds
> and the final assembly.
>
> So, is there a way to build the library with multiple compilers in one go?

Let msvc2010 and msvc2013 be the two profiles you've set up.
Then you can call qbs like this:
 qbs build release profile:msvc2010 release profile:msvc2013

The "build" command can be omitted.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Bug with QiTools submodule on osX

[Joerg Bornemann]

On 03-Jun-14 11:25, olivier musse wrote:

> I would just like to rise up something which look like a bug on osX.
> While Qt submodule uitools is working on windows, it seems not to
> include lib and path on mac.

That's a bug. The Qt.uitools module is linked as framework on OS X, 
which is wrong. Qt.uitools is a static library.
I've created QBS-608 for this.


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Setting up the run environment in QtCreator

[Joerg Bornemann]

On 03-Jun-14 08:54, Thomas Epting wrote:

> class QBS_EXPORT RunEnvironment
> { ...
>  const QProcessEnvironment runEnvironment() const;
>  const QProcessEnvironment buildEnvironment() const;
>
> The implementations call setupXxxEnvironment of the resolvedProduct and
> return the created environment. Note that the second method is not
> strictly needed, but I thought it would be nice to have it also. If
> there is a better way to get the environments, please correct me ;-)

That's OK for now. Ideally, Qt Creator would use 
RunEnvironment::runTarget to run the application. But the infrastructure 
isn't fit for that yet.
So enhancing the API is in order IMO.

> Next, I tried to implement the missing functionality like this.
>
> void QbsRunConfiguration::addToBaseEnvironment(Utils::Environment &env)
> const
> {
[...]
>  QtSupport::BaseQtVersion *qtVersion =
> QtSupport::QtKitInformation::qtVersion(target()->kit());
>  if (qtVersion)
>
> env.prependOrSetLibrarySearchPath(qtVersion->qmakeProperty("QT_INSTALL_LIBS"));
> }

I wonder why the QT_INSTALL_LIBS part is needed. This should be done by 
the setupRunEnvironment script in the Qt.core module. There seems to be 
something amiss there. Not in your code - in the plugin or qbs itself.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Get product property from another product

[Joerg Bornemann]

On 02-Jun-14 15:10, Denis Shienkov wrote:

> are available any way to get a product property, similar with a module
> property way?
>
> e.g. by analogy with Module:
>
> var moduleProperty = product.moduleProperties(moduleName, propertyName) ;
>
> but only for Product:
>
> var productProperty = product.poductProperties(productName, propertyName) ;
>
> It is possible?

If the product you want to query is a dependency of the current product 
you can traverse product.dependencies:

for (var i in product.dependencies) {
 var dep = product.dependencies[i];
 print(dep.name);
}

With product.dependencies you can access the dependency tree of the 
current product.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Fwd: Function to enumerate all files in desired directory

[Joerg Bornemann]

> E.g. I need to add all *.qm files from the /translations output
> directory to my WiX project file. This *.qm files  automatically are
> copied into this directory from the all sub-products of my Project (at
> building of my Project)..
> I hoped that I will be able to make it by means of qbs. Now I in the
> deadlock... bad bad..  Need to find out some workaround.. :(

Can't think of a good work-around right now. As last resort you can 
always create some script that creates or extends the WiX project file 
and call it from your rule/transformer.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Function to enumerate all files in desired directory

[Joerg Bornemann]

On 30-May-14 14:01, Denis Shienkov wrote:

> 1)
>
> It is possible to create an some JS function to return a list of all
> available files (e.g. by a file mask or extension) in target directory?
>
> function(targetDirectory, fileMaskOrExtension) {
>  var fullFilePaths = [];
>  ...
>  ...
>  return fullFilePaths;
> }
>
> maybe similar core (example) is already exists in Qbs sources and so on?
> (but I can not find anything similar ...)

As of now there's no such function in JS context. The files properties 
of Product and Group support wildcards though.
Without extending the built-in JS extensions I don't see a good way to 
implement such a function... apart from an ugly hack by calling ls/dir 
and parsing the output.
Having such a function would be useful. Care to create a suggestion?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Just a few questions

[Joerg Bornemann]

On 28-May-14 23:46, Kevin Chaves wrote:

> The other odd thing I noticed is that the working directory for a
> command isn't created...

I don't think it's a good idea to let the command create its working 
directory. A mistake in the working dir property could create strange, 
unintended directory layouts.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Run some rules in "build" or "deploy" or custom step.

[Joerg Bornemann]

On 23-May-14 11:38, Denis Shienkov wrote:

> A main question is:
> it is possible to do something that my Products (Rules of module) was
> launched only in appropriate steps?
> or, it is possible to introduce an custom additional steps (not only
> Build, Install, Deploy) ?

Not yet. But soon (QBS-262).


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Get property from parent project

[Joerg Bornemann]

On 22-May-14 16:14, Christian Kandeler wrote:
> On 05/22/2014 04:00 PM, Tim Hutt wrote:
>> Relatedly, how can I access properties from a Rule's prepare script?
>> E.g. this does not work - it thinks foo is not defined.
>>
>>  Rule  {
>>  property  string  foo:  "baz"
>>  prepare:  {
>>  var  /a = foo;/
>
> Yeah, Rules (much like Artifacts) are not first-class items in that they
> don't really support adding custom properties in a meaningful way (i.e.
> you can't access them later from prepare scripts). Maybe that is worth
> changing. Jörg, what's your opinion on this?

I recommend to not make the properties of the Rule item visible in 
Rule.prepare for the following reasons:
   1. The variable inputs that is available in Rule.prepare clashes with 
the property Rule.inputs.
   2. Making the other properties visible doesn't come for free. You'd 
need special cases. E.g. should prepare be visible in prepare?
   3. The gain is questionable. What's the advantage compared to 
defining variables at the start of the script or defining the properties 
outside the Rule item?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] compile designer plugin

[Joerg Bornemann]

On 22-May-14 23:47, olivier musse wrote:
> It looks like I found myself the solution :
> Only need to QDESIGNER_EXPORT_WIDGETS to cpp.defines.

Yes, that's the only thing that's done in qmake's designer_defines.prf.
Not sure whether a dedicated property for designer plugins is justified.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Generate pre compiled headers

[Joerg Bornemann]

On 22-May-14 19:28, olivier musse wrote:

> I'm sure it is possible to find a solution even if not optimal.

I've created QBS-595 for this.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Generate pre compiled headers

[Joerg Bornemann]

On 21-May-14 00:08, olivier musse wrote:

> 1) The file pch_headers.h is well generated on the build directory if in
> my PchHeaders Group I select files with extension other than .h . When
> I use .h extension, the pch_headers.h is not generated as if there are
> some interferences between the cpp module "hpp" tag and my "pch" tag.
> Does it may be the issue? Can I do something for it to work?

This should work... but it doesn't - as I just noticed.
I've created QBS-593 to track this.

> 2) the line
> cpp.cxxPrecompiledHeader:product.buildDirectory+"/pch_headers.h" seem to
> have no effect when put in the Module. I try to put it directly in the
> product and then it warn me that the artifact is not in the list of
> source files. For the pch_headers.h to be pre compiled, I need to put it
> manually in the source directory and add to project

Right. What you're trying to do is highly dependent on the current 
implementation of the PCH handling in the cpp module. We never designed 
it for this use case.
Not sure whether this is possible without altering the implementation in 
the cpp module.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] qbs & qt creator

[Joerg Bornemann]

On 22-May-14 16:02, Thomas Epting wrote:

>  > In Qt Creator 3.2 we will include the qbs command-line frontend, so
>  > such workarounds shouldn't be necessary anymore.
>
> Btw ... are there any plans to integrate IncrediBuild + Qbs with
> QtCreator? By now it is very tricky to use this combination from within
> QtCreator.

No concrete plans, but to enable IncrediBuild with qbs one would have to 
call xgconsole with the qbs executable. This isn't supported by the 
QbsProjectManager plugin (yet).
The binary package (and the git repo) contains the files ibqbs.bat and 
ibmsvc.xml that can be used together with IncrediBuild on the commandline.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Duplicate product name

[Joerg Bornemann]

On 19-May-14 10:11, olivier musse wrote:

> I understand why it is working like that in qbs since it creates a build
> tree.
> What I think is missing is the possibility to just aggregate projects so
> that there are all builds as if there are separate projects => separate
> build tree, separate output directory.
> Is there any way to do that ?

Sounds a lot like QBS-282.


BR,

Joerg

___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Generating rc file

[Joerg Bornemann]

On 16-May-14 15:29, olivier musse wrote:

> Just one last question if I can : Does the folder hierarchy
> modules/generateRC/generateRC.qbs  can be change.
> I have found 2 projects properties which are QbsSearchPath and
> moduleSearchPath but moduleSearchPath seems to have been removed and do
> not succeed to make QbsSearchPath works.

moduleSearchPaths was deprecated and later removed. qbsSearchPaths is 
the property to use now. The folder hierarchy cannot be changed. 
However, you can name the generateRC.qbs as you like. The module name is 
the folder name below "modules".

> Today I use .pri files to do that and they are in this hierarchy (from
> main project folder)
> IMPORT/Qi/tools/generateRC.pri
> How can I transpose with qbs  knowing that i can add subfolders if
> necessary but need to keep the IMPORT/Qi/tools folder

Sorry, I didn't grasp that. Could you elaborate what you're trying to 
achieve?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to setup an custom profile without Qt?

[Joerg Bornemann]

On 17-May-14 20:15, Denis Shienkov wrote:

> 3) There is possible to use some configuration file to setup my profile
> automatically at once?
>
> e.g. like something:
>
> qbs-config "myprofile.cfg"

What would be the content of that configuration file?
Isn't a script enough that has a bunch of qbs-setup-toolchains and 
qbs-config calls?
Or do you want to save a profile to an external and later restore it?

> 4) It is possible to use of my custom qbs profile from the QtCreator using 
> QbsProjectManager?

No, at the moment the QbsProjectManager exclusively uses the Kit 
infrastructure of Qt Creator. Maybe a way to specify an "external qbs 
profile" would be cool.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Generating rc file

[Joerg Bornemann]

On 16-May-14 12:59, olivier musse wrote:

> 2) What is the best solution (Module, Product...)  to put this
> transformer and group in a separate file I can use from any project with
> a simple Depends{ name : "generated.qbs"} call  or something equivalent.
> I have tried using another product, but in this case the properties
> (product.version) are not the one of the calling product and it is
> impossible to automatically add the file to the calling product.
> (Export{files:["generatedRC"}} does not work

Sorry, I didn't see your 2nd question. :)
Create a file modules/generateRC/generateRC.qbs in your project root 
directory. Wrap your transformer with a Module item like this:

Module {
 Transformer {
  // your code
 }
}

Then you can use it in your products like this

Product {
 Depends { name: "generateRC" }
}


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Error at using multiple artifacts for module's rule

[Joerg Bornemann]

On 16-May-14 13:44, Denis Shienkov wrote:

>  Artifact  {
>  condition:  product.moduleProperty("qbs",  "generateListing")
>  fileTags:  [  "keil_lst"  ]
>  fileName:  ".lst/"  +  product.name    +  
> "/"  +  FileInfo.baseName(input.filePath)  +  ".lst"
>  }

This output artifact has a condition. If that condition is false, which 
it is by default, there will be no keil_lst artifact in the outputs.

You probably wanted to write
 product.moduleProperty("keil",  "generateListing")
assuming that your module is called keil.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Generating rc file

[Joerg Bornemann]

On 16-May-14 12:59, olivier musse wrote:

>  Artifact  {
>  fileName:  "generated.rc"
>  fileTags:  "generatedRC"
>  }

Qbs doesn't know what "generatedRC" is. To be picked up by the resource 
compiler rule, you must specify the "rc" file tag.

Artifact  {
 fileName:  "generated.rc"
 fileTags:  ["rc"]
}


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] share functionnality between projects

[Joerg Bornemann]

On 14-May-14 14:31, olivier musse wrote:

> What is the best way to share source files and functionality among
> different projects.

If you don't the source compiled built with different build settings, 
then I recommend creating a static library, like you did.

Source file collections (like .pri files) are not supported yet. But 
there's suggestion QBS-59 for this feature.

One can achieve something similar by using inheritance and/or .js files. 
It's just not that nice.

> 2) How to share functionality between projects.
>   As an example, imagine I want to automatically generate a file
> according to project properties
[...]
> I would like the transformer to be share among many projects so that I
> only need to include in the project file a qbs file only containing this
> transformer.
> What is the best solution to do that ?

Put the transformer to a separate file, e.g. mytrafo.qbs.
Then import it
import "somewhere/mytrafo.qbs" as MyTrafo
and instantiate it
MyTrafo {
// and maybe override properties here
}


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Version and product name

[Joerg Bornemann]

On 14-May-14 11:13, olivier musse wrote:

> For qmake, this is not limited to version, there are :
> QMAKE_TARGET_COMPANY, QMAKE_TARGET_PRODUCT, QMAKE_TARGET_COPYRIGHT and
> we are using it today. This is somewhat important for us.

It's limited to the VERSIONINFO section (in the rc file) I meant, which 
contains all these variables. :)
Anyways, it would be nice to have such an autogerated .rc file. It could 
also contain a ICON resource.


Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Version and product name

[Joerg Bornemann]

On 14-May-14 10:49, olivier musse wrote:

> 1) event with settings name and version property in my product, the
> generated executable have nothing set in its properties (version,
> product). With qmake the rc file is automatically generated. Is there
> something equivalent with qbs?

Currently, no rc file is automatically generated. This qmake feature is 
limited to the VERSION variable anyways, so I didn't adapt it to qbs.
You need to create your rc file manually and add it to the files list of 
the product.

> 2) using a 1.2.0 version, when I include "import qbs 1.2" I get the
> following message. Is this normal
>Incompatible qbs version 1.2. This is qbs 1.0.

Hmm yes, I see how this can be confusing. The version number in the 
"import qbs" statement is the "language version" and not the qbs 
version. Just keep it as 1.0 for now.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Newbie to QBS

[Joerg Bornemann]

On 13-May-14 10:37, olivier musse wrote:

> If somebody have time to help hereafter is a list of questions :
> - When compiling a project with QBS it always start a command windows.
> How to remove this behavior?

You can set consoleApplication to false in your product. That will 
result in adding the /SUBSYSTEM:WINDOWS switch to the linker.

> - How can I perform a post link process as it can be done with
> QMAKE_POST_LINK

There's not a post link step in qbs.
But you can achieve the same by doing these steps:
- set your product type to something like "myapp"
- create a rule that takes "application" as input and creates 
"myapp" outputs
- specify your post link commands in that rule

> - what is the simplest way to install the list of Qt libraries (only
> needed ones) beside the executable ?

In Qt5 is a tool named windeployqt for that purpose. That's not 
restricted to qbs and can be used independent of the build tool.

> - is there any way to override the install root from the qbs file ?

The install root is passed as parameter to the "qbs install" command.
E.g. qbs install --install-root C:\somewhere\else
This is usually an absolute path on the build machine which is most 
likely unknown to the author of the project files.
You want to set the default for that in your project file?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] qbs 1.2.0 released

[Joerg Bornemann]

On 06-May-14 07:38, Yuchen Deng wrote:

> sounds great! does any plan to support Android in 1.3?

Yes, we plan to eventually have Android support in 1.3.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] How to change build directory of a Product?

[Joerg Bornemann]

On 03-May-14 22:40, Jake Petroules wrote:

>> 2. I have found that the object file that is getting created if I
>> build the QBS project has the name "X.c.o" if the file name is
>> "X.c". How can I configure QBS to name the object file as "X.o"?
>>
> We did this so that having multiple files with the same base name but
> different extensions will not cause an error. For example, if you have
> both file.c and file.cpp, both cannot be built into file.o as this
> causes a conflict. Currently you cannot change the naming scheme of
> object files but given a good reason we may add a way for users to
> configure it. Is there a specific reason you need your object files
> named X.o?

Also, we're considering the build directory to be opaque for the user. 
The directory layout and naming conventions of files should not matter.

I have the same question like Jake. What's your use case?

>> 3. Moreover the object files are getting generated in a folder ".obj"
>> in the default build directory. How to configure this also?
>>
> This is currently not user-configurable but probably should be.

Probably. But here as well: what's the use case?

>> I am new to QBS as well as writing applications in C so any help
>> regarding my above queries would be much appreciated. I shall also
>> like to make some observations on QBS build system and its documentation.
>> 1. I believe QBS is a very flexible build system, at least it appears
>> so to me. But the documentation is very poor for a newcomer.
>> Specifically, elaborate documentation is needed in the areas like
>> Transformer, Rule (both multiplex and non-multiplex), Module, etc.
>>
> Qbs is a very new product so we still have a lot of work to do in this
> area but it's definitely on the roadmap.

That's unfortunately true. Please ask on this mailing list, if 
something's unclear. We'll try to extend the docs in those areas.

>> 4. It is not obvious from documentation how to create custom build
>> jobs in QBS. For example lets say in my project I have flex/bison
>> files along with other C files and I want to build those flex/bison
>> files first with respective tools before compiling all the C files.
>> How to specify this custom step?
>>
> You'd do this using custom Rules, Transformers, and Modules. I remember
> another user had written some Qbs scripts to handle flex/bison files;
> perhaps we can add built-in support at some point. Again, this is
> something that more extensive documentation could help with as you noted
> in (1).

There's an example in tests/auto/blackbox/testdata/codegen and another 
in tests/auto/blackbox/testdata/dynamicRuleOutputs.
We should move them over to the examples directory.


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Building of external projects

[Joerg Bornemann]

On 22-Apr-14 16:42, Denis Shienkov wrote:

> Whether it is planned to support in QBS a feature to build of an
> external projects?

That is not planned as such but looks like a nice feature. Care to 
create a suggestion in JIRA?


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] FW: Preserving independent module-properties when applying rules

[Joerg Bornemann]

On 11-Mar-14 14:55, johannes.mato...@microchip.com wrote:

> Unfortunately I don't have any good idea of how this could be done better.
> For the moment I use a combination of two workarounds:
>
> 1. For external modules I add support for the properties to my preprocessor 
> module
>
> 2. For internal modules I add a project property that contains a mapping 
> file-name -> property
>
> Both are not really nice but at least they work and the overhead is 
> acceptable.
>
> One idea (although I don't think that it's a good one) might be to allow 
> enumeration and programmatic generation of module properties. This way one 
> could use them in situations we haven't thought of yet.
>
> Enumeration could be done with functions like file.moduleCount(), 
> file.moduleAt(index), file.modulePropertyCount(module), 
> file.modulePropertyAt(module, index) or something similar.

I don't think that I completely understand this approach.
How would your initial use case be solved with those functions?


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Obtaining paths to objcopy, size, etc

[Joerg Bornemann]

On 26-Feb-14 10:13, Fatih Aşıcı wrote:

> I am using qbs for my bare metal projects. I need paths to
> arm-none-eabi-objcopy/size.
>
> Currently, I get them using:
>
> propertypathobjcopyPath:cpp.compilerPath.replace(/gcc(.exe)?$/,"objcopy$1")
>
> propertypathsizePath:cpp.compilerPath.replace(/gcc(.exe)?$/,"size$1")
>
> But this seems ugly. Profiles created with "qbs setup-toolchains" have a
> cpp.toolchainPrefix
>
> property to hold target triplet but Qt Creator (3.0.1) does not set this
> variable.

Right. Qt Creator ideally should set toolchainPrefix and 
toolchainInstallPath.

> This property could be useful to generate paths to such tools; but it
> might be better to
>
> have variables like cpp.objcopyPath declared by qbs.

The objcopy tool isn't used ATM by qbs. That's why there's no such 
property. If we're going to introduce such properties, where do we draw 
the border? Do we provide a path for every program in binutils?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Preserving independent module-properties when applying rules

[Joerg Bornemann]

On 21-Feb-14 11:15, johannes.mato...@microchip.com wrote:

> How can I preserve the module-properties without adding specific code
> for each possible property to the preprocessor module?

Right. The output artifacts of a rule inherit the properties that are 
set on the product. We could provide a flag for output artifacts to 
inherit the properties from the input artifact.
Downside: this would be restricted to rules that take exactly on input 
artifact.

Any thoughts on how to solve this more generally or smarter?


BR,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Run all tests

[Joerg Bornemann]

On 18-Feb-14 12:31, Иван Комиссаров wrote:

> If i understand you correctly, you want to list all products that are built 
> using qbs and run products which name starts with "tst_".
>
> I have the same issue - i need to list all products. Is that possible?

We've removed the "list all properties in the project" feature on 
purpose, because we saw no good use case for it. Apologies to you guys 
who actually relied on it.

The "run all tests" use case is covered, once we've implemented action 
targets, like "make tests" in qmake projects (QBS-262).

Until then we could

1) bring back the removed feature.

2) extend the project object with information about the products. This 
would be nice anyways and wouldn't be a temporary hack.

One could write a project information file with all containing products 
or properties or whatever like this:

Transformer {
 Artifact { fileName: "projectinfo.txt"; fileTags: ["stuff"] }
 prepare: {
 var cmd = new JavaScriptCommand();
 cmd.description = "creating stuff";
 cmd.sourceCode = function() {
 var f = new TextFile(output.fileName, TextFile.WriteOnly);
 f.write(JSON.stringify(project));
 f.close();
 }
 return [cmd];
 }
}

The project object doesn't hold much valuable information at the moment 
but you get the idea. What do you think?


Cheers,

Joerg
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs