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] 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] 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

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] 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] 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] 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] 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] 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 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] 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] 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 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] 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] 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

[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] 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

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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] complex name: and this name depend

[Joerg Bornemann]

On 07.11.2013 15:25, Oleg Shalnev wrote:

 I am trying to understand the possibilities of creating complex modules name

Not sure, if I understand your problem correctly, but the following 
works fine:


property string blubb: .widgets
Depends { name: Qt + blubb }


Where is SomePostFix/OtherPostFix declared?


Cheers,

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

Re: [QBS] New item ProductFolder

[Joerg Bornemann]

On 03/06/2013 20:32, Jochen Becher wrote:

 Of course nested projects could also be done. But especially the
 implementation within qbs source code makes nested projects not the
 first choice to me (ResolvedProjects contains attributes and methods
 which are really only used from the top-level project and will not make
 any sense within a nested project, won't they?)

Sure, that's how it looks now. But the code can be changed.

 Furthermore I would like to allow having ProjectFolder as a root element
 within a referenced qbs file (currently only product is allowed here).
 Having a Project as a root element in referenced qbs files would
 introduce some kind of fuzziness of the project/product concept.

No, it must be possible to reference a subproject that can be built as 
stand-alone project as well. This would be impossible with the 
ProjectFolder approach.
Also, I don't want to enforce the Project item in qbs files that are 
referenced as subproject. In that case that SubProject thingy basically 
acts as logical grouping for display purposes, very much like a folder.


BR,

Joerg

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

Re: [QBS] Qbs Roadmap

[Joerg Bornemann]

On 31/05/2013 14:29, Jochen Becher wrote:

 in my company we are currently trying to switch from Visual Studio with
 Qt plugin to QtCreator. We were running into some conceptional problems
 with qmake so we are currently looking into Qbs as an alternative.

Just out of curiosity, could you tell us what these conceptional 
problems are in detail?

 We understand that Qbs' integration into QtCreator is still not ready
 for daily use (e.g. because of issue QBS-19 and others) so I would like
 to know if there is any detailed roadmap of Qbs for the next months.

QBS-19 (add possibility to add files to qbs projects in Qt Creator) is 
just about adding files via right-mouse click and a context menu. You 
can add files by directly editing the project file of course.

The roadmap can be viewed in JIRA. It is reachable via the main project 
page https://bugreports.qt-project.org/browse/QBS
There are the planned future versions visible. Every accepted issue got 
a version assigned to it that indicates when they are supposed to be fixed.


BR,

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

Re: [QBS] Project structure

[Joerg Bornemann]

On 23/05/2013 08:21, Orgad Shaneh wrote:

 The project consists of 2 static libraries (call them lib1 and lib2) and
 a target executable (call it app).

 I need some advice regarding the preferred qbs project structure.

  1. lib1 and app share some of the defines and include paths (lib2 is
 somewhat disjoint).

You might want to add common values into a .js file and use those in 
lib1 and app. Or you add properties to the Project item and reference 
them in lib1 and app.

  2. I have multiple build variants. All of them are debug builds, but
 each variant uses a different define and 2 of the variants exclude
 some of the source files.

Is your question how to define custom build variants?

  3. I would like to have some sort of configuration that outsources the
 actual build operation to an external script. I do need though to
 have defines and include paths correctly parsed (in Creator) and for
 external builds I also have multiple configurations (some flags are
 strings, some are booleans). With qmake I use PRE_TARGETDEPS and
 place the sources in a dummy scope. Is there a way to do this with qbs?

Display-only files for Qt Creator can be put into a Group item with a 
false condition. You can call your build script from a Transformer item. 
See tests/manual/transformers for an example.

  4. The include paths list is quite long. Is there a way to use a
 wildcard for it like it is done for sources?

No. But you could generate and load a .js file that contains the include 
paths.


BR,

Joerg

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

Re: [QBS] (no subject)

[Joerg Bornemann]

On 15/05/2013 18:28, Kakadu wrote:

 Now qbs take source file and generates result in  build folder. I have 
 compiler which takes source files and places result always in the same 
 folder. Is it possible to hack qbs to copy source file to build directory and 
 built it there? How difficult is it?

You'd have to add a copy command before the actual compiler call. 
Something like this:

---snip---
Rule {
 ...
 prepare: {
 ...
 var commands = [];
 // copy source file
 var cmd = new Command(cp, [input.fileName, 
FileInfo.path(output.fileName));
 commands.push(cmd);
 // now the actual compiler call
 cmd = new Command(g++, args);
 commands.push(cmd);
 return commands;
 }
}
---snap---

Instead of calling cp you can use a JavaScript command and copy the file 
via File.copy in a platform-independent way, if you want.


BR,

Joerg

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

Re: [QBS] Thoughts about processor architecture

[Joerg Bornemann]

On 21/03/2013 01:44, Jake Thomas Petroules wrote:

 First off is `qbs.supportedArchitectures`. This variable would hold a
 list of all architectures that the compiler can generate code for.

Fine, this should be detectable.

 Second is `qbs.defaultArchitectures`. This variable would hold a list of
 the architectures that the compiler will generate by default.

What would the value be for MSVC where there's a separate compiler 
binary per target architecture?

Could we explicitely pass the architecture argument to gcc/clang in 
every case and not rely on the default?

 Lastly is `qbs.targetArchitectures`. This variable would default to the
 value of `qbs.defaultArchitectures` and would be read-write, allowing the
 developer to specify which architectures they would like to compile for.

If there's postprocessing involved for combining builds, then this 
should be a property of some kind of meta project that builds a 
subproject with different build configurations and then does something 
with the build result(s). I agree with Ossi that this looks a lot like 
like a list of profiles.


Cheers,

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