Re: [Qbs] qbspkgconfig in qbs 2.3.1

[Иван Комиссаров]

The «fallback» provider will be removed in 2.4.

Ivan

> 7 июня 2024 г., в 22:40, Jochen Becher  написал(а):
> 
> 
> By total accident, I discovered different solution:
> 
> Depends { name: "taglib"; enableFallback: true }
> 
> Is using the property enableFallback an official way to use pkg-config
> or will that be removed in a future version of qbs?
> 
> Regards, Jochen
> 
> 
> Am Sonntag, dem 02.06.2024 um 19:04 +0300 schrieb Иван Комиссаров:
>> Hello!
>> 
>> Short answer:
>> 
>> Use qbsModuleProviders: ["Qt", "qbspkgconfig"]
>> 
>> A longer answer: 
>> 
>> Setting qbsModuleProviders property disables «named» lookup for
>> providers when Qbs tries to guess provider name from the module name
>> (e.g. «Qt» from «Qt.core») .
>> 
>> The "named" lookup exists for backward compatibility and we advise
>> listing providers explicitly in the new node.
>> 
>> Ivan
>> 
>>> 1 июня 2024 г., в 13:21, Jochen Becher via Qbs 
>>> написал(а):
>>> 
>>> Hi,
>>> 
>>> I tried to build a project for the first time after a couple of
>>> years
>>> and qbs versions. I now use QtCreator 13.0.1 with qbs 2.3.1.
>>> 
>>> The product is a StaticLibrary and has dependencies
>>> 
>>> Depends { name: "Qt", submodules: ["core" , "gui"] }
>>> Depends { name: "taglib" }
>>> 
>>> In the past "taglib" has been resolved by the default fallback for
>>> pkgconfig.
>>> 
>>> I added
>>> 
>>> qbsModuleProviders: "qbspkgconfig"
>>> 
>>> in the hope to get the correct settings for taglib. But now, qbs
>>> fails
>>> with the following error message:
>>> 
>>> mediadb-extras.qbs:13: warning: Dependency 'Qt.core' not found for
>>> product 'mediadb-extras'.
>>> 
>>> What I am doing wrong? I couldn't find an example showing
>>> dependencies
>>> to Qt and a pkgconfig provided library.
>>> 
>>> I am running on Ubuntu 22.04 using Qt 5.15.2.
>>> 
>>> Regards, Jochen
>>> 
>>> ___
>>> Qbs mailing list
>>> Qbs@qt-project.org
>>> https://lists.qt-project.org/listinfo/qbs
>> 
> 

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

Re: [Qbs] qbspkgconfig in qbs 2.3.1

[Иван Комиссаров]

Hello!

Short answer:

Use qbsModuleProviders: ["Qt", "qbspkgconfig"]

A longer answer: 

Setting qbsModuleProviders property disables «named» lookup for providers when 
Qbs tries to guess provider name from the module name (e.g. «Qt» from 
«Qt.core») .

The "named" lookup exists for backward compatibility and we advise listing 
providers explicitly in the new node.

Ivan

> 1 июня 2024 г., в 13:21, Jochen Becher via Qbs  
> написал(а):
> 
> Hi,
> 
> I tried to build a project for the first time after a couple of years
> and qbs versions. I now use QtCreator 13.0.1 with qbs 2.3.1.
> 
> The product is a StaticLibrary and has dependencies
> 
> Depends { name: "Qt", submodules: ["core" , "gui"] }
> Depends { name: "taglib" }
> 
> In the past "taglib" has been resolved by the default fallback for
> pkgconfig.
> 
> I added
> 
> qbsModuleProviders: "qbspkgconfig"
> 
> in the hope to get the correct settings for taglib. But now, qbs fails
> with the following error message:
> 
> mediadb-extras.qbs:13: warning: Dependency 'Qt.core' not found for
> product 'mediadb-extras'.
> 
> What I am doing wrong? I couldn't find an example showing dependencies
> to Qt and a pkgconfig provided library.
> 
> I am running on Ubuntu 22.04 using Qt 5.15.2.
> 
> Regards, Jochen
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Setting properties for all products

[Иван Комиссаров]

You can put the other_project_buildconfig module in your projects search paths 
- that way it will override subproject module.

Here QtC overrides Qbs buildconfig 
https://github.com/qt-creator/qt-creator/blob/master/qbs/modules/qbsbuildconfig/qbsbuildconfig.qbs

However, this requires some discipline from subprojects.


> 29 мая 2024 г., в 01:25, Richard Weickelt  написал(а):
> 
> 
> That solution breaks as soon as you include other Qbs projects that are not 
> under your control as sub-projects.
> 
> I still find a global Preference item useful or a default-dependencies 
> property in the project item that attaches a module dependency to all 
> products.
> 
> Richard
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] qbs 2.3 released

[Иван Комиссаров]

It seems we forgot to write the file.

Hopefully, the blog post will cover the details.

Ivan

> 9 апр. 2024 г., в 11:37, Leon Buckel  написал(а):
> 
> Where can we find the changlog? It doesn’t seem to be in the usual location.
> 
>> On 8. Apr 2024, at 12:52 PM, Christian Kandeler via Qbs  
>> wrote:
>> 
>> [You don't often get email from qbs@qt-project.org. Learn why this is 
>> important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> Hi,
>> 
>> we have released qbs 2.3.0 today.
>> 
>> As usual, sources, binaries, change log etc can be found here:
>> https://download.qt.io/official_releases/qbs/2.3.0/
>> 
>> This release of qbs is also part of Qt Creator 13.0.0.
>> 
>> 
>> Christian
>> 
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Code Generator with shared library dependencies

[Иван Комиссаров]

I think, this is the official way to do so.

You are not supposed to run binaries from build dir. 
If Qbs does not ensure that files are installed prior to usage, this should be 
fixed.
 
Ivan

> 12 янв. 2024 г., в 13:10, Leon Buckel  написал(а):
> 
> In the past I’ve solved this problem by deploying the tool and dlls first and 
> running it from the install root.
> That still works but doesn’t seem right.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Fwd: Accessing overloaded properties

[Иван Комиссаров]

Fwd to the mail list

> 
> Hello!
> 
> We typically discourage usage of the id properties (the only use-case are 
> Probes for the lack of other syntax) since Qbs is more «context» dependent 
> and we provide some «magic» variables such as «product», «importingProduct» 
> and so on.
> 
> You can use id prop if it works for you (but note that for e.g. Depends items 
> id is not the id of the Depends item itself, but and alias for the imported 
> module).
> 
> There are some other ways do do this. First, you can introduce an 
> intermediate property to resolve the conflict:
> 
> MyProject {
>   installDir: "myfolder"
>   property string _temp: installDir
> 
>   MyProject {
>   installDir: _temp + "/mysubfolder"
>   }
> }
> 
> You can also try using «parent» variable but that’s not documented either and 
> I’m not sure it’s OK to use it.
> 
> Ivan
> 
>> 8 янв. 2024 г., в 14:37, Jochen Becher via Qbs  
>> написал(а):
>> 
>> Happy New Year!
>> 
>> I havbe a question about qbs syntax. My qbs files look like this:
>> 
>> MyProject.qbs:
>> 
>> Project {
>>  property string installDir: { throw "installDir must be set" }
>> }
>> 
>> AProject.qbs:
>> 
>> MyProject { 
>>   id: solution
>>   installDir: "myfolder"
>> 
>>   MyProject {
>>   installDir: solution.installDir + "/mysubfolder"
>>   }
>> }
>> 
>> My question is about"solution.installDir". Using "project.installDir"
>> doesn't work. "outer.installDir" or "base.installDir" is also not
>> allowed or not what I want.
>> 
>> But I am not sure if defining "id" and using it in a subitem like in
>> QML is really supported. It works and is sometimes but it is not
>> documented in the qbs manual.
>> 
>> Is using the id element correct? If not, what is the correct way to
>> accomplish this?
>> 
>> Regards, Jochen
>> 
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 

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

Re: [Qbs] No functional TLS backend warning

[Иван Комиссаров]

Hi, we’ve ported Qbs to Qt6 a while ago - maybe it caused the issue?

It might be that runtime deps in Brew formulae are not configured properly for 
Qt6.

Ivan 

> 26 окт. 2023 г., в 17:33, Leon Buckel  написал(а):
> 
> Hi,
> 
> With the current qbs version 2.1.2 (maybe earlier 2.x ones too) installed on 
> macOS via homebrew, we get lots of console output with these messages:
> qt.network.ssl: No functional TLS backend was found
> qt.network.ssl: No TLS backend is available
> 
> This warning is from Qt itself and not qbs but it didn’t appear with previous 
> versions which use the same homebrew installed Qt (6.5.2) so it looks like a 
> qbs issue.
> 
> It does affect the builds too as the Utilities.signingIdentities function 
> returns an empty object for the subjectInfo because it fails to read the 
> certificate.
> 
> Does anybody have an idea what’s wrong here?
> 
> Regards
> 
> Leon
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] get path of qbs executable within Project/Product?

[Иван Комиссаров]

Hello, I don’t think this is possible. What’s your use-case?

Ivan

> 5 окт. 2023 г., в 18:02, Heiko Nardmann  
> написал(а):
> 
> 
> Hi together,
> 
> is it possible to get the folder resp. path of the qbs executable from within 
> a Project or Product item?
> 
> 
> 
> Kind regards,
> 
>   Heiko
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Windows 11 & (major|minor)-subsystem-version

[Иван Комиссаров]

Maybe the fix is trivial after all 
https://codereview.qt-project.org/c/qbs/qbs/+/471291

Can someone verify this on Win7?

Ivan

> 10 апр. 2023 г., в 23:31, Иван Комиссаров  написал(а):
> 
> Hello!
> 
> Someone reported an issue a while ago and I created a ticked just yesterday 
> in order to to not forget it.
> https://bugreports.qt.io/projects/QBS/issues/QBS-1724
> 
> I suppose, the issue was introduced by this patch 
> https://codereview.qt-project.org/c/qbs/qbs/+/459921 which was an attempt to 
> fix Qbs build with mingw - mingw headers are broken in a way that the old 
> value leaded to incorrect macros in Windows.h
> 
> If you find a way to fix Qbs build and actual binaries, you’re welcome to 
> submit a patch.
> 
> Note that CMake sets (major|minor)-subsystem-version to 0 (unconditionally?) 
> when building for mingw.
> Maybe you can set those to 0 for _linking_ while setting the correct 
> WINVER/whatever macro Qbs sets for _compiling_.
> 
> Also, this should be fixed by mingw upstream - otherwise those flags are 
> useless.
> 
> Ivan

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

Re: [Qbs] Windows 11 & (major|minor)-subsystem-version

[Иван Комиссаров]

Hello!

Someone reported an issue a while ago and I created a ticked just yesterday in 
order to to not forget it.
https://bugreports.qt.io/projects/QBS/issues/QBS-1724

I suppose, the issue was introduced by this patch 
https://codereview.qt-project.org/c/qbs/qbs/+/459921 which was an attempt to 
fix Qbs build with mingw - mingw headers are broken in a way that the old value 
leaded to incorrect macros in Windows.h

If you find a way to fix Qbs build and actual binaries, you’re welcome to 
submit a patch.

Note that CMake sets (major|minor)-subsystem-version to 0 (unconditionally?) 
when building for mingw.
Maybe you can set those to 0 for _linking_ while setting the correct 
WINVER/whatever macro Qbs sets for _compiling_.

Also, this should be fixed by mingw upstream - otherwise those flags are 
useless.

Ivan


> 10 апр. 2023 г., в 22:42, Björn Schäpers  написал(а):
> 
> Good Day,
> 
> I was recently forced to use Windows 11 at work and was puzzled why many of 
> my programs (but not all!) failed to start with the code 0xc7b. After a 
> lot of investigation I found the issue to be the subsystem values.
> 
> All affected programs use Qt, which sets the minimum windows version to 10, 
> and the gcc.js (I'm using MinGW) uses this value for the os version as well 
> as the said subsystem version. And those programs do not start on Windows 11, 
> Windows 10 had no problems with that.
> 
> I've inspected a few programs, I've found none which didn't set the value 
> (and the os version too by the way) to anything higher than 6. That includes 
> the CMake generated Qt programs (moc, qmake, etc.) and Microsoft programs 
> like Notepad, Teams, and Outlook.
> 
> I help myself with omitting the parameters right now. What is your take on 
> that? If I propose a patch to not set the subsystem version, does it have a 
> chance to be accepted?
> 
> I've not tested anything with MSVC, but would except the same behavior since 
> it just sets the field in the PE header.
> 
> Kind regards,
> Björn.
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Qbs 1.23.2 released

[Иван Комиссаров]

I think, both RPATH and RUNPATH should work.

Do I understand correctly that you use self-built QtC and you built it using 
Qbs?

In that case, that might be a bug in how QtC project overrides Qbs rpaths.

Ivan

> 26 окт. 2022 г., в 12:15, Карелин Павел  написал(а):
> 
> Christian, does it make sense to add construct 
> 
> cpp.driverLinkerFlags: [ 
> "-Wl,--disable-new-dtags", 
> ] 
> 
> to the project code QBS?
> 
> Or is this problem on Ubuntu only I have?
> 
> On the other hand, the people on the internet writes that RUNPATH is a more 
> correct approach (for example here: 
> https://stackoverflow.com/questions/51952784/embed-rpath-instead-of-runpath-in-when-building-shared-objects-on-ubuntu-18-04
>  
> )
> 
> 
> What do you think about this?
> 
> --
> Pavel
> 
> P.S. 
> When QBS is builded as an independent project (outside QtC), this case 
> everything works even with RUNPATH. Although, perhaps there is some "magic" 
> with paths. In my system directly states the path to standalone-QBS project 
> (/etc/profile.d/qbs.sh => export PATH=$PATH:/opt/qbs/bin)
> 

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

Re: [Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects

[Иван Комиссаров]

> Why would the item pool use `std::vector m_items;` instead of a QList 
> ( Or QVector ) ?  I imagine it was a performance consideration, but it always 
> puzzles me to see stdlib in most qt code.
There were plans to migrate to pure stdlib and some parts of the code have been 
ported already which leads to unnecessary convertions in some places.
Also, most of the time we do not need QVector’s COW and we don’t need to write 
qAsConst on containers.
I generally use std containers in new code unless we benefit from COW to save 
some memory

> Should Project and Product remain the only top level Items? Or would there be 
> reason to let GenericItem{}​ do so also? I am thinking to keep it as is.
Probably those should be left as is.

> There are three Values -- Item, JSSource, and Variant. I have only been able 
> to create JSSource when making a qbs file. What are the other two used for?
Product {
name: "p"
property string foo: "foo"; // this is jsvalue UNLESS it is overriden from 
CLI, e.g. 'qbs resolve products.p.foo:bar’, in that case it is Variant Value

Depends { name: «cpp» }
property string bar: cpp.defines // cpp here is an ItemValue, while 
cpp.defines is a js or variant value as above
}

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

Re: [Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects.

[Иван Комиссаров]

+1 here.

Maybe Object (or Gadget/smth else since JS has “object” type already) as it is 
not a generic Item used in other items would be better.

Otoh if we choose the Item { id/name: foo } syntax, Item would be fine.

Ivan

> Perhaps also:
> 
> property MyItem prop
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects.

[Иван Комиссаров]

This seems like a nice idea, I was wondering the same thing myself if can we 
enforce the “schema” on object properties.

Иван Комиссаров

> 2 сент. 2022 г., в 05:14, hug-animals via Qbs  написал(а):
> 
> 
> Greetings. I've been using QBS for quite awhile and have been expanding its 
> use to do things other than build c++ projects. I have run up onto a 
> limitting factor, and so I would like to make a language proposal to fix this.
> 
> Proposal: 
> Generic `Item` for classifying bindable properties.
> 
> What does this look like?
> 
> Product {
> /* Syntax 1 */
> property var feed: Item {
> property string hobo
> property var seed: Item {
> property string chuck 
> }
> }
> 
> /* Syntax 2 */
> Item {
> id: feed // unique ID to Product
> property string hobo
> Item {
> id: seed
> property string chuck 
> }
> }
> 
> /* Syntax 3 */
> Item {
> name: "feed" // unique name to Product
> property string hobo
> Item {
> id: seed
> property string chuck 
> }
> }
> }
> 
> 
> /* In use */
> import "Sneed.qbs" as Sneed
> 
> Sneed {
> feed.hobo  : "Hobo"
> feed.seed.chuck: "Chuck"
> }
> 
> 
> What do you mean, "Classifying"?
> Sub Properties, stemming from a singular name, like `feed.hobo:` -- `feed` 
> becomes the class, `hobo` becomes the property.
> 
> Why not use modules to do this?
> Modules can only exist in certain elements. `Item` should exist for every 
> module. [Unless specifically blacklisted]
> 
> Is this important?
> Yes, insofar as it reduces namespace pollution in a practical way that is 
> currently impossible.
> 
> What do you need this for? 
> In short, I am creating an expansive probe with hundreds of potential 
> properties. Namespace pollution has become an issue, as well as encapsulation.
> 
> Why not name things `feed_seed_chuck:` instead of `feed.seed.chuck:`? 
> It may be the case, that I do not want to use anything from `feed` at all. It 
> is much easier to check for `feed`s initialization than individually for 
> `feed_seed_check` and `feed_hobo`.
> 
> Are you willing to program this?
> I have ~8 years experience as a Qt developer, and some time to throw at this.
> 
> Potential Drawbacks:
> - This does depart a bit from QML syntax rules.
> 
> What sort of feedback are you looking for?
> - Is there any inherent opposition on technical grounds?
> - What is the ideal syntax?
> - General thoughts.
> 
> Thank you for your time and consideration.
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Dynamic generation of the resource file

[Иван Комиссаров]

You can just do 


outputArtifacts: {
return [{
fileTags: input.fileTags.contains("encription") ? ["encript-resource"] 
: ["encript-resource2"],
filePath: FileInfo.joinPaths(project.buildDirectory, "encription", 
input.baseName + ".enc")
}];
}


Ivan

> 8 окт. 2021 г., в 10:45, Карелин Павел  написал(а):
> 
> Hi. 
> 
> Ivan, only now have "reached the hands" to see your decision. Everything 
> turned out, the only thing at first I created two separate rules (according 
> to the rule for each group). It looked like a flaw. However, then I figured 
> out how to make a universal rule. See comment-section "Variant 1" and 
> "Variant 2" in the attached file.
> 
> Denis, Ivan, thank you for your help in solving this problem!
> 
> BR, Pavel

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

[Qbs] 1.21 branch created

[Иван Комиссаров]

Hello,

We branched off Qbs 1.21 today. Scheduled release date for
version 1.21.0 is end of November (together with Qt Creator 6.0) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently under review can be moved if they are reasonably close to
finished.

Ivan

[1] https://wiki.qt.io/Qt_Creator_Releases 

[2] http://download.qt.io/snapshots/qtcreator/6.0/ 
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Dynamic generation of the resource file

[Иван Комиссаров]

In Qbs, you can set properties for individual files using Group item:

Qt.core.resourceFileBaseName: "trigrams"
Group {
fileTagsFilter: [«qrc_input1»] // trigrams-map in your example
fileTags: ["qt.core.resource_data»]
Qt.core.resourcePrefix: «prefix1"
}

Group {
fileTagsFilter: [«qrc_input2»]
fileTags: ["qt.core.resource_data»]
Qt.core.resourcePrefix: «prefix2"
}

Looking into Qt.core code, it supports multiple prefixes like that. Multiple 
qrc files in one Product are not supported though - this can be implemented, 
but no one needed this so far.

Ivan

> 2 окт. 2021 г., в 17:01, Карелин Павел  написал(а):
> 
> Denis, if you can suggest how to generate a second resource file - I will 
> only be glad.
> 
> Now I assume that the name of the dynamic resource file depends on the 
> parameters  
>   Qt.core.resourceFileBaseName: "trigrams"
>   Qt.core.resourcePrefix: "trigrams"
>   
> And I don't understand how to specify another file name.  
> 
> --
> Pavel
> 
> 02.10.2021 09:17, Denis Shienkov пишет:

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

Re: [Qbs] IRC: Freenode -> Libera.Chat ?

[Иван Комиссаров]

Hello, most of the community moved to the Discord server 
https://discord.gg/5mFfku5y  - looks like IRC was 
not very popular, so there were no plans to move it to Libera.Chat.

Ivan

> 13 авг. 2021 г., в 15:28, Heiko Nardmann  
> написал(а):
> 
> Hi together,
> 
> is QBS IRC also moving to Libera.Chat ?
> 
> 
> 
> Kind regards,
> 
>   Heiko
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Library- and Include-Probe for msys GCC on the example of the protobuf module

[Иван Комиссаров]

Sorry for the long response.

The idea is that Qbs will use custom parser of .pc files - this allows us to 
work with dependencies between .pc files and convert them to deps between qbs 
modules which is not possible via pkg-config tool API. So you don’t really need 
pkg-config binary to be present in the system. However, if it is present, Qbs 
will use its libdirs automatically. So you will have 2 options - either pass 
path to 32 bit pkg-config or set libdirs manually (it is also possible to have 
some hardcoded values in Qbs, maybe depending on the toolchain? dunno)

Ivan

> 21 июля 2021 г., в 22:55, Björn Schäpers  написал(а):
> 
> Thanks for the response.
> 
> This is fine for me. And yes msys provides .pc files, but that leaves me with 
> another problem, at least when used from the QtCreator. I only have 
> pkg-config from my 64 bit system in the path, an thus when compiling for 32 
> bit the wrong libraries are picked up.
> 
> Regards,
> Björn.
> 
> Am 21.07.2021 um 07:16 schrieb Иван Комиссаров:
>> You will get more feedback once I’ll be back from vacation ^^
>> 
>> Your assumption that it should work out if the box is correct.
>> 
>> However, it should not use probes, but pkg-config instead (I assume, msys 
>> provides correct .pc files).
>> 
>> I am currently working on the feature to implement this .
>> 
>> https://codereview.qt-project.org/c/qbs/qbs/+/315910
>> 
>> https://codereview.qt-project.org/c/qbs/qbs/+/350654
>> 
>> Ivan
>> 
>>> 21 июля 2021 г., в 03:07, Björn Schäpers  
>>> написал(а):
>>> 
>>> Hi there,
>>> 
>>> my setup is msys2 gcc in 64 and 32 bit, a from msys installed protobuf, and 
>>> a self compiled qbs. The protobuf module does not find the header or the 
>>> libraries, it seems the search path is just empty, and for the libraries it 
>>> looks for the wrong files. It searches protobuf.lib, but the file is named 
>>> libprotobuf.a.
>>> 
>>> I have prepared a patch, with which the protobuf examples compile and run: 
>>> https://codereview.qt-project.org/c/qbs/qbs/+/358698 my colleagues tells me 
>>> for gRPC there are some additional libraries missing, but that's another 
>>> point.
>>> 
>>> There is little feedback on the patch, only that I could set the paths in 
>>> my project file. Yes I could, but in my opinion it should work out of the 
>>> box with a msys setup. But the wrong library names and suffixes I can not 
>>> fix in my project file, or can I?
>>> 
>>> So my questions are:
>>> 1. Should it be fixed in qbs itself, or do I have to make a fork?
>>> 2. Should it be fixed in the protobuf module, or the probes itself?
>>> 
>>> Greetings,
>>> Björn.
>>> ___
>>> Qbs mailing list
>>> Qbs@qt-project.org
>>> https://lists.qt-project.org/listinfo/qbs
> 
> 

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

[Qbs] 1.20 branch created

[Иван Комиссаров]

Hello,

We branched off Qbs 1.20 today. Scheduled release date for
version 1.20.0 is mid of August (together with Qt Creator 5.0) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently under review can be moved if they are reasonably close to
finished.

Ivan

[1] https://wiki.qt.io/Qt_Creator_Releases 

[2] http://download.qt.io/snapshots/qtcreator/5.0/ 
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Library- and Include-Probe for msys GCC on the example of the protobuf module

[Иван Комиссаров]

You will get more feedback once I’ll be back from vacation ^^

Your assumption that it should work out if the box is correct.

However, it should not use probes, but pkg-config instead (I assume, msys 
provides correct .pc files).

I am currently working on the feature to implement this .

https://codereview.qt-project.org/c/qbs/qbs/+/315910

https://codereview.qt-project.org/c/qbs/qbs/+/350654

Ivan

> 21 июля 2021 г., в 03:07, Björn Schäpers  написал(а):
> 
> Hi there,
> 
> my setup is msys2 gcc in 64 and 32 bit, a from msys installed protobuf, and a 
> self compiled qbs. The protobuf module does not find the header or the 
> libraries, it seems the search path is just empty, and for the libraries it 
> looks for the wrong files. It searches protobuf.lib, but the file is named 
> libprotobuf.a.
> 
> I have prepared a patch, with which the protobuf examples compile and run: 
> https://codereview.qt-project.org/c/qbs/qbs/+/358698 my colleagues tells me 
> for gRPC there are some additional libraries missing, but that's another 
> point.
> 
> There is little feedback on the patch, only that I could set the paths in my 
> project file. Yes I could, but in my opinion it should work out of the box 
> with a msys setup. But the wrong library names and suffixes I can not fix in 
> my project file, or can I?
> 
> So my questions are:
> 1. Should it be fixed in qbs itself, or do I have to make a fork?
> 2. Should it be fixed in the protobuf module, or the probes itself?
> 
> Greetings,
> Björn.
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Settings module properties globally in root qbs project?!

[Иван Комиссаров]

Hello!

The module approach you’ve suggested is probably the best way of doing this. 
Requires some additional work, unfortunately.

I’d also suggest adding helper items that inherit base items provided by Qbs, 
such as CppApplication, DynamicLibrary, etc - in that case, you can use these 
items as a drop-in replacement and have a single place where you can add new 
functionality, such as the dependency on the module that sets identities. I 
have a small project to illustrate the idea - e.g. see 
https://github.com/ABBAPOH/qbsfish/blob/master/qbs/imports/MyApp.qbs 
 Qbs 
itself uses the same approach

Ivan


> 7 июня 2021 г., в 13:07, q...@mein-briefkasten.net написал(а):
> 
> Hello,
> 
> I’m currently migrating our project to qbs 1.19 and make use of the new 
> codesign module.
> 
> When doing so especially on iOS I need to switch between different mobile 
> provisions and thus code signing identities depending on the type of build 
> and my project contains of many sub-projects. When setting the right codesign 
> properties in the main app qbs file only I get many resolve errors for 
> missing code sign identities for each lib sub project.
> 
> I can resolve this issue to set the right properties using the qbs command 
> line, e.g.
> 
>> qbs resolve config:release profile:qt5_15_3@ios ... -f app_standalone.qbs 
>> --build-directory ~/build/ios-test1 modules.codesign.signingIdentity:”my 
>> identity” modules.codesign.provisioningProfilesPath:”path-to-profiles”
> 
> But then every user has to do configure this on its own, but I would like to 
> setup the default configuration in the root qbs project.
> 
> Is this somehow possible?
> 
> Of course I could create a qbs module for this, but then I would need to 
> Depend on it in every lib/exe product qbs file. I would prefer a global 
> solution.
> 
> Cheers,
> Maximilian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication

[Иван Комиссаров]

Hello!. In the second variant - do you need 

Group {
fileTagsFilter: "application"
fileTags: "trigrams-generator"
}

? The product has that type already

I’d say both variants are OK and there’s no preference.

> 1 марта 2021 г., в 21:43, Карелин Павел  написал(а):
> 
> Colleagues, hello.
> 
> It's a bit of a pity that I didn't get an answer to the last question, but 
> it's okay.  There is a working option, and it can be used. 
> Christian, Alberto, thanks for helping to solve my problem. 
> 
> --
> BR, Pavel
> 
> 
> 22.02.2021 19:07, Карелин Павел пишет:
>> Christian, I experimented a little, and got another variant.
>> 
>> Your variant (clarification: the generation of trigrams in binary form is 
>> performed by the parsetrigrams utility) :
>> 
>> Product {
>> name: "ParseTrigrams"
>> targetName: "parsetrigrams"
>>   
>> type: ["application"]
>> ...
>> files: [
>> "parsetrigrams.cpp"
>> ]
>> 
>> Group {
>> fileTagsFilter: "application"
>> fileTags: "trigrams-generator"
>> }
>> }
>> 
>> Product {
>> name: "QGit"
>> targetName: "qgit"
>> 
>> type: "application"
>> 
>> Depends { name: "cpp" }
>> Depends { name: "ParseTrigrams" }
>> Depends { productTypes: ["trigrams-generator"] }
>> Depends { name: "Qt"; submodules: ["core", "widgets"] }
>> 
>> Group {
>> fileTags: "trigrams"
>> files: FileInfo.joinPaths(product.sourceDirectory, 
>> "spellcheck/sonnet/trigrams/*")
>> }
>> 
>> Group {
>> fileTagsFilter: ["trigrams-map"]
>> fileTags: ["qt.core.resource_data"]
>> }
>> Qt.core.resourceFileBaseName: "trigrams"
>> Qt.core.resourcePrefix: "trigrams"
>> 
>> Rule {
>> id: idtrigrams
>> inputs: ["trigrams"]
>> explicitlyDependsOnFromDependencies: ["trigrams-generator"]
>> 
>> Artifact {
>> fileTags: ["trigrams-map"]
>> filePath: FileInfo.joinPaths(project.buildDirectory, "trigrams", 
>> input.baseName + ".tmap")
>> }
>> prepare: {
>> var runUtl = 
>> explicitlyDependsOn["trigrams-generator"][0].filePath
>> var outputFile = FileInfo.joinPaths(project.buildDirectory, 
>> "trigrams", input.baseName + ".tmap");
>> 
>> var cmd = new Command(runUtl, [input.filePath, outputFile]);
>> cmd.description = "sonnet parse trigrams";
>> cmd.highlight = "filegen";
>> return cmd;
>> }
>> }
>> 
>> files: [
>> "qgit.cpp",
>> ]
>> }
>> 
>> My variant:
>> 
>> Product {
>> name: "ParseTrigrams"
>> targetName: "parsetrigrams"
>> 
>> type: ["application", "trigrams-generator"]
>> ...
>> files: [
>> "parsetrigrams.cpp"
>> ]
>> Group {
>> fileTagsFilter: "application"
>> fileTags: "trigrams-generator"
>> }
>> }
>> 
>> Product {
>> name: "QGit"
>> 
>> type: "application"
>> 
>> Depends { name: "cpp" }
>> Depends { productTypes: ["trigrams-generator"] }
>> Depends { name: "Qt"; submodules: ["core", "widgets"] }
>> 
>> Group {
>> fileTags: "trigrams"
>> files: FileInfo.joinPaths(product.sourceDirectory, 
>> "spellcheck/sonnet/trigrams/*")
>> }
>> 
>> Group {
>> fileTagsFilter: ["trigrams-map"]
>> fileTags: ["qt.core.resource_data"]
>> }
>> Qt.core.resourceFileBaseName: "trigrams"
>> Qt.core.resourcePrefix: "trigrams"
>> 
>> Rule {
>> id: idtrigrams
>> inputs: ["trigrams"]
>> explicitlyDependsOnFromDependencies: ["trigrams-generator"]
>> 
>> Artifact {
>> fileTags: ["trigrams-map"]
>> filePath: FileInfo.joinPaths(project.buildDirectory, "trigrams", 
>> input.baseName + ".tmap")
>> }
>> prepare: {
>> var runUtl = 
>> explicitlyDependsOn["trigrams-generator"][0].filePath
>> var outputFile = FileInfo.joinPaths(project.buildDirectory, 
>> "trigrams", input.baseName + ".tmap");
>> 
>> var cmd = new Command(runUtl, [input.filePath, outputFile]);
>> cmd.description = "sonnet parse trigrams";
>> cmd.highlight = "filegen";
>> return cmd;
>> }
>> }
>> 
>> files: [
>> "qgit.cpp",
>> ]
>> }
>> 
>> The differences are as follows:
>> For ParseTrigrams:
>> type: ["application"]
>> vs
>> type: ["application", "trigrams-generator"]
>> 
>> For QGit:
>> Depends { name: "ParseTrigrams" }
>> Depends { productTypes: ["trigrams-generator"] }
>> vs
>> Depends { productTypes: ["trigrams-generator"] }
>> 
>> 
>> I would like to know if there is a fundamental difference in these 
>> solutions, and which variant is preferable? 
>> 
>> --
>> BR, Pavel
>> 
>> 
>> 
>> 22.02.2021 13:00, Christian Kandeler пишет:
>>> On 2/19/21 5:43 PM, Карелин Павел wrote: 
 Project QGit__micro is attached. 
 The situation is 

Re: [Qbs] (no subject)

[Иван Комиссаров]

Hello, Dan! Any chance you publish your solution? I am interested in wasm 
support as well

Ivan

>  
> The goal is to get qbs projects compiled to WebAssembly using the emscripten 
> toolchain (and Qt WebAssembly). As for upstreaming: I have managed to come up 
> with a working but hacky solution (a small test project) which I believe has 
> room for improvement. 
> 
> 

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

Re: [Qbs] Qt6 support

[Иван Комиссаров]

Did you install this module using the MaintenanceTool? It doesn’t get installed 
by default

Ivan

> 4 дек. 2020 г., в 10:44, Maximilian Hrabowski  
> написал(а):
> 
> Hi all,
> 
> Is Qt6 already supported by qbs?If so which version is required? Doing a 
> naive “Depends { name: “Qt.core5compat” } with abs 1.17 did not work ;)
> 
> Best regards,
> Maximilian Hrabowski
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] AutotestRunner in QtCreator

[Иван Комиссаров]

I personally use the «tests» tab (on the bottom panel) in QtCreator - it allows 
to run all tests (similar to building AutotestRunner) as well as running tests 
in single file.
Similar to AutotestRunner, QtC recognizes products with the tag «autotest» as 
tests

Ivan

> 28 нояб. 2020 г., в 20:44, Björn Schäpers  написал(а):
> 
> Am 24.11.2020 um 14:19 schrieb Richard Weickelt:
>>> 2. Build the AutorestRunner product explicitly. It will not show up under 
>>> "run".
>>> That's what I meant, I can not select it as a run target.
>>> And I don't know how to say "just build product X", if it's not a run 
>>> target.
>> In the Projects view, right-click on the autotest-runner product and in the 
>> context menu click on Build or Rebuild.
> Thanks. :)
>> You can also set the builtByDefault property to true, then it is built when 
>> hitting ctrl-b.
> That I don't want at all, actually I'm setting it to false for all my tests 
> right now.
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Why was protobuf.outputDir removed

[Иван Комиссаров]

As I said before, I have no objections to bring the property back.

Just add a test so we know why we need this property and add custom tags for 
the generated files to separate them from the other header files.

Ivan.

> 16 сент. 2020 г., в 08:27, Kai Dohmen via Qbs  написал(а):
> 
> Hello Ivan,
> 
> the use-case of installation arises from encapsulating the proto files into a 
> single library. I do this because then it is easier for me to use the 
> proto-stuff in different applications.
> Since I started to use conan to track dependencies I needed to compile and 
> install the static library for use in the consuming application.
> I would rather append the proto files to an products source files If there is 
> a (non hacky) way to it (with conan),
> 
> Kai
> 
> 
> 
> Am Di., 15. Sept. 2020 um 09:41 Uhr schrieb Иван Комиссаров 
> mailto:abba...@gmail.com>>:
> Hello, Kai
> 
> First of all, the property was not removed but was made «private» and is now 
> called _outputDir. You can still override it or read it.
> 
> The reason why it was removed is that I didn’t see valid use-cases for that.
> 
> For example, to export include paths you should do something like that:
> 
> StaticLibrary {
> files: [«a.cpp», «b.proto»]
> Depends { name: «protobuf.cpp» }
> Export {
>  Depends { name: «protobuf.cpp» } // this should export protobuf.cpp 
> properties, including cpp.IncludePath
> }
> }
> 
> However, your second use-case (installation) is totally new to me and it 
> seems that you need to read this property.
> Unless someone can suggest a better solution, feel free to upload a patch to 
> return the property.
> You might also want to assign custom tags for generated files (e.g. 
> «proto_hpp», «proto_cpp») to make filtering more fine-grained and avoid 
> overlapping with other headers.
> 
> Ivan
> 
> > 15 сент. 2020 г., в 09:00, Kai Dohmen via Qbs  > <mailto:qbs@qt-project.org>> написал(а):
> > 
> > Hello,
> > 
> > the subject states my Question.
> > Normally I create a static library from proto files. This static library 
> > can be linked into different applications. This really comes in handy when 
> > using conan.
> > But since protobuf.outputDir was removed I cannot set the Exported 
> > includePaths dir properly.
> > Furthermore when installing the generated header files I cannot use the 
> > Groups property installSourceBase to match the installed directory 
> > structure to the proto files ones.
> > 
> > What is the right way of using proto files as a library? Should they get 
> > compiled or should they append to the depending products source files?
> > 
> > Thanks,
> > Kai
> > ___
> > Qbs mailing list
> > Qbs@qt-project.org <mailto:Qbs@qt-project.org>
> > https://lists.qt-project.org/listinfo/qbs 
> > <https://lists.qt-project.org/listinfo/qbs>
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Why was protobuf.outputDir removed

[Иван Комиссаров]

This won’t work in case of the protoc - the generated tree does not always 
match the tree in the source and it depends on the order of the -I flags passed 
to protoc.

Ivan

> 15 сент. 2020 г., в 10:35, Oswald Buddenhagen  
> написал(а):
> 
> On Tue, Sep 15, 2020 at 09:00:50AM +0200, Kai Dohmen via Qbs wrote:
>> Furthermore when installing the generated header files I cannot use the
>> Groups property installSourceBase to match the installed directory
>> structure to the proto files ones.
>> 
> that's actually an interesting one. the general idea is to get rid of 
> accessible output dirs to make the build dirs as opaque as possible.  
> however, this obviously defies installSourceBase usage with generated files 
> (the original use case was to install trees of data files that are not 
> generated). i think the way out would be finding the *sources* of the 
> installed artifacts (if necessary, recursively), as their layout is actually 
> controllable by the user, and consequently expect the base to point into the 
> source tree. this shall fail if an artifact has multiple primary sources 
> coming from different directories.
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Why was protobuf.outputDir removed

[Иван Комиссаров]

Hello, Kai

First of all, the property was not removed but was made «private» and is now 
called _outputDir. You can still override it or read it.

The reason why it was removed is that I didn’t see valid use-cases for that.

For example, to export include paths you should do something like that:

StaticLibrary {
files: [«a.cpp», «b.proto»]
Depends { name: «protobuf.cpp» }
Export {
 Depends { name: «protobuf.cpp» } // this should export protobuf.cpp 
properties, including cpp.IncludePath
}
}

However, your second use-case (installation) is totally new to me and it seems 
that you need to read this property.
Unless someone can suggest a better solution, feel free to upload a patch to 
return the property.
You might also want to assign custom tags for generated files (e.g. 
«proto_hpp», «proto_cpp») to make filtering more fine-grained and avoid 
overlapping with other headers.

Ivan

> 15 сент. 2020 г., в 09:00, Kai Dohmen via Qbs  написал(а):
> 
> Hello,
> 
> the subject states my Question.
> Normally I create a static library from proto files. This static library can 
> be linked into different applications. This really comes in handy when using 
> conan.
> But since protobuf.outputDir was removed I cannot set the Exported 
> includePaths dir properly.
> Furthermore when installing the generated header files I cannot use the 
> Groups property installSourceBase to match the installed directory structure 
> to the proto files ones.
> 
> What is the right way of using proto files as a library? Should they get 
> compiled or should they append to the depending products source files?
> 
> Thanks,
> Kai
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Applying cxxFlags to certain files

[Иван Комиссаров]

You can access the original value via input.cpp.prop:

fileTags: [tag],
filePath: outputDir + "/" + FileInfo.baseName(input.fileName) + suffix,
cpp: {
includePaths: [].concat(input.cpp.includePaths, outputDir),
warningLevel: "none",
}

> 10 июля 2020 г., в 13:42, Dan Pat  написал(а):
> 
> I have checked out the solution and discovered an inconvenience. As it 
> stands, Artifacts are passed to the "cpp" module  with flags set by the 
> Product (and product imported Modules) in the context of which the Artifacts 
> are built. But as soon as I set the Artifact specific "cpp.cxxFlags" , they 
> seem to replace, instead of being appended to (desired behaviour), the 
> Product-wise flags. Can you suggest any clean way to deal with this?
> 
> 
> пт, 10 июл. 2020 г. в 14:34, Dan Pat  >:
> Ah, I was looking directly at it and still didn't notice the 
> "cpp.cxxLanguageVersion" part. Thank you.
> 
> пт, 10 июл. 2020 г. в 13:33, Richard Weickelt  >:
> > Hi. I have a code generator, encapsulated in a dedicated Module, producing
> > c++ source files. The generator's artifacts are then picked up by the
> > "cpp"
> > module according to the rules. For such generated files (and for them
> > only)
> > I would like to pass certain flags to the compiler (to suppress certain
> > warnings) but I cannot figure out how. Any ideas are welcome. Regards.
> 
> Have a look at the code example here: 
> https://doc.qt.io/qbs/qml-qbslanguageitems-artifact.html 
> 
> 
> If you use the outputArtifacts property of the Rule item instead, it should 
> work very similar:
> 
> outputArtifacts: [{filePath: "myfile.cpp", fileTags: ["cpp"], cpp: { 
> someFlag: "value" }}]
> 
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] building android aab package help

[Иван Комиссаров]

Interesting, I do not get that error. Maybe Christian knows better why this 
could happen?

The following example works for me on Mac:

CppApplication {
name: qbs.profile
consoleApplication: true
Profile {
name: "a"
baseProfile: project.profile
cpp.defines: 'MAGIC_MACRO="a"'
}
Profile {
name: "b"
baseProfile: project.profile
cpp.defines: 'MAGIC_MACRO="b"'
}
qbs.profiles: ["a", "b"]
files: [ "main.cpp" ]
install: true
installDir: "bin"
}

Note, that I had to change the product name, otherwise I get a conflict - there 
are 2 artifacts with the same name which are built to the same location (which 
is reasonable, but should not be your case).
Also, I have to set consoleApplication to ‘true' since there’s a bug macOS 
bundle module - the product is not linked at all when trying to multiplex 
profiles. Should not be a problem in your case either.
The bottom line is that I get 2 binaries, a and b each getting it’s own defines.

Ivan

> 7 июня 2020 г., в 14:18, Raphael Cotty  написал(а):
> 
> Hi,
> Looking into that...
> 
> So I have a simple example like that:
> Application {
> Profile {
> name: "a"
> baseProfile: project.profile
> }
> Profile {
> name: "b"
> baseProfile: project.profile
> }
> qbs.profiles: ["a", "b"]
> files: [ "main.cpp"
> ]
> }
> I get this error: Result of expression 'qbs.targetOS' [undefined] is not an 
> object. In NativeBinary.qbs
> 
> Am I missing something here? The targetOS property is not set when the 
> Profile appears in the Product?
> Thanks
> Raph
> 
> 
> Le dim. 7 juin 2020 à 10:51, Иван Комиссаров  <mailto:abba...@gmail.com>> a écrit :
> Hello, Raphael!
> 
> I’ve seen your new patch and it looks really interesting.
> 
> So, for now, you have 2 separate patches for the AAB support, right?
> [0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 
> <https://codereview.qt-project.org/c/qbs/qbs/+/303358>
> [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 
> <https://codereview.qt-project.org/c/qbs/qbs/+/289726>
> 
> The multiplexing over type seems to be a very useful feature, but I’m afraid 
> it’s not that easy to implement. I find it useful to multiplex a library over 
> "staticlibrary"/"dynamiclibrary" types, but how do I link to such a 
> multiplexed library? I am not sure it’s the simplest way to go.
> 
> I would like to suggest similar solution which would not require (at least, 
> for now) radically changing the way how multiplexing works.
> Could you please try this approach:
> 1. Introduce "property string packageType" with 2 (3 values?) - «apk», «aab», 
> (undefined?) in the sdk module and make rules dependent on that. Undefined 
> could be used for console applications (see below).
> 2. Change the type of the Android product from «android.apk» to 
> «android.package» (or even simply use «application» if possible)
> 3. Set the new property in the Application.qbs by default, e.g. to preserve 
> the old behavior, you can do like this:
> NativeBinary {
> type: isForAndroid && !consoleApplication ? «Android.package» : 
> «application» // could it be simply «application»?
> sdk.packageType: !consoleApplication ? «apk» : undefined
> }
> 
> Now, you want to build both apk and aab in one go. You can use multiplexing 
> over profiles:
> 
> Application {
> Profile {
> name: «a»
> sdk.packageType: «apk»
> baseProfile: project.profile
> }
> Profile {
> name: «b»
> sdk.packageType: «aab»
> baseProfile: project.profile
> }
> qbs.profiles: [«a», «b»]
> }
> 
> Will that work? If no, would it be possible to make it working?
> Note that this is pseudo code, feel free to change the details.
> 
> Ivan.
> 
>> 17 апр. 2020 г., в 13:03, Raphael Cotty > <mailto:raphael.co...@gmail.com>> написал(а):
>> 
>> The android tool aapt2 manages resources. Some output files required for the 
>> aab package need to be in the protobuf format. Also the R.java generated by 
>> aap2 is different from apk to aab.
>> That's what I meant by context.
>> The aab package doesn't need the apk package to be built.
>> 
>> Because both packages need exactly the same input and because some of the 
>> rules are the same (java ones, dex one) I think it makes sense to build both 
>> packages by the same product.
> 

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

Re: [Qbs] building android aab package help

[Иван Комиссаров]

Hello, Raphael!

I’ve seen your new patch and it looks really interesting.

So, for now, you have 2 separate patches for the AAB support, right?
[0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 

[1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 


The multiplexing over type seems to be a very useful feature, but I’m afraid 
it’s not that easy to implement. I find it useful to multiplex a library over 
"staticlibrary"/"dynamiclibrary" types, but how do I link to such a multiplexed 
library? I am not sure it’s the simplest way to go.

I would like to suggest similar solution which would not require (at least, for 
now) radically changing the way how multiplexing works.
Could you please try this approach:
1. Introduce "property string packageType" with 2 (3 values?) - «apk», «aab», 
(undefined?) in the sdk module and make rules dependent on that. Undefined 
could be used for console applications (see below).
2. Change the type of the Android product from «android.apk» to 
«android.package» (or even simply use «application» if possible)
3. Set the new property in the Application.qbs by default, e.g. to preserve the 
old behavior, you can do like this:
NativeBinary {
type: isForAndroid && !consoleApplication ? «Android.package» : 
«application» // could it be simply «application»?
sdk.packageType: !consoleApplication ? «apk» : undefined
}

Now, you want to build both apk and aab in one go. You can use multiplexing 
over profiles:

Application {
Profile {
name: «a»
sdk.packageType: «apk»
baseProfile: project.profile
}
Profile {
name: «b»
sdk.packageType: «aab»
baseProfile: project.profile
}
qbs.profiles: [«a», «b»]
}

Will that work? If no, would it be possible to make it working?
Note that this is pseudo code, feel free to change the details.

Ivan.

> 17 апр. 2020 г., в 13:03, Raphael Cotty  написал(а):
> 
> The android tool aapt2 manages resources. Some output files required for the 
> aab package need to be in the protobuf format. Also the R.java generated by 
> aap2 is different from apk to aab.
> That's what I meant by context.
> The aab package doesn't need the apk package to be built.
> 
> Because both packages need exactly the same input and because some of the 
> rules are the same (java ones, dex one) I think it makes sense to build both 
> packages by the same product.

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

Re: [Qbs] isystem with clang

[Иван Комиссаров]

Hello, you can find the generated modules in the build directory.

$ pwd
/Users/abbapoh/Programming/qt5/alien/qbs/examples/helloworld-qt

$ qbs
Build graph does not yet exist for configuration 'default'. Starting from 
scratch.
Resolving project for configuration default
Setting up Qt at '/Applications/Qt/5.14.2/clang_64/bin/qmake'...
Qt was set up successfully.
...

$ ll default/genmodules/Qt/a779ea9613ba57bb/modules/Qt/
total 16
...


> 20 мая 2020 г., в 12:39, Christian Gagneraud  написал(а):
> 
> 
> BTW, with this "new" (to me) Qt module provider, are the files
> generated and store on disk, i can't seem to find them anywhere.

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

Re: [Qbs] Binary stripping

[Иван Комиссаров]

It looks like strip is only used in android and Darwin toolchains

Maybe, it’s makes sense to add a rule that strips binary in the release mode as 
well

Ivan

> 9 апр. 2020 г., в 21:49, Alberto Mardegan  
> написал(а):
> 
> Hi all!
>  Sorry for spamming the list :-)
> I noticed that binaries generated by mingw are quite large, and when I
> ran the "strip" command on them, the size was reduced by more than half,
> without losing functionality.
> 
> I'm building my application with the `config:release` option. Shouldn't
> that run "strip" on the generated binaries? I see that QBS seems to be
> strip-aware already (there are the stripName and stripPath options in
> the cpp module), but it appears that their usage is only triggered if
> separate debug information is requested.
> 
> Is there a reason why "strip" is not invoked when in release mode?
> 
> Ciao,
>  Alberto
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Changing the default value of consoleApplication

[Иван Комиссаров]

I don’t mind adding QtWidgetsApplication item

Ivan

> 8 апр. 2020 г., в 22:33, Alberto Mardegan  
> написал(а):
> 
> On 08/04/20 13:21, Oswald Buddenhagen wrote:
>> i'm not convinced. qt.widgets and qt.quick could reasonably do that, but
>> gui is perfectly suitable for console-only apps.
> 
> mmm... you are right, there might be a QtGuiApplication which uses
> QImage to do some processing but never creates a window.
> 
> One might still argue that that's not such a common use-case, and that
> it can anyway be overridden. I'll wait for some more opinions :-)
> 
> Ciao,
>  Alberto
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Q_INIT_RESOURCE on Windows

[Иван Комиссаров]

From the Qt documentation:

"The Q_INIT_RESOURCE() macro is necessary on some platforms for resources 
stored in a static library.»

This is a workaround to tell the linker not to throw resources away when 
linking a static library.

It is not required when using a dynamic library as far as I remember.

Ivan

> 7 апр. 2020 г., в 21:26, Alberto Mardegan  
> написал(а):
> 
> Hi there!
>  I was about to write this to the QtProject mailing list, but then I
> got the doubt that this might be a QBS issue, so I thought of double
> checking with you guys first.
> 
> I'm building a GUI application which comes with a shared library which
> contains some Qt resources that need to be made available to the
> application.
> 
> However, on windows the build fails, both natively (you can check the
> AppVeyor logs here [1]) and cross-compiled with MXE from Linux. The
> error is:
> 
> ==
> main.cpp.obj : error LNK2019: unresolved external symbol "int __cdecl
> qInitResources_mappero_ui(void)" (?qInitResources_mappero_ui@@YAHXZ)
> referenced in function main
> C:\projects\mappero\default\mappero.a4d1648d\mappero.exe : fatal error
> LNK1120: 1 unresolved externals
> ==
> 
> The main.cpp files contains Q_INIT_RESOURCE(mappero_ui), and a file
> 
>  release/MapperoUi.e4550a40/qrc_mappero-ui.cpp
> 
> is present in the build directory, and it contains (among a lot of other
> stuff) the lines:
> 
> ==
> int QT_RCC_MANGLE_NAMESPACE(qInitResources_mappero_ui)();
> int QT_RCC_MANGLE_NAMESPACE(qInitResources_mappero_ui)()
> {
>int version = 3;
>QT_RCC_PREPEND_NAMESPACE(qRegisterResourceData)
>(version, qt_resource_struct, qt_resource_name, qt_resource_data);
>return 1;
> }
> ==
> 
> I checked with the nm tool (provided by MXE), and the dll library indeed
> contains the qInitResources_mappero_ui() symbol; however, the symbol is
> not present in the MapperoUi.lib file generated in the same directory.
> 
> Shouldn't the symbol in the generated qrc_mappero-ui.cpp file be wrapped
> in a Q_DECL_EXPORT() macro?
> 
> Could it be that this is a qbs bug, that for some reason it does not
> invoke rcc with the right options?
> 
> Ciao,
>  Alberto
> 
> [1] https://ci.appveyor.com/project/mardy/mappero/builds/31993601
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Changing the default value of consoleApplication

[Иван Комиссаров]

consoleApplication is set to undefined by default which means «use the default 
compiler value» which seems to be «console» on Windows

But I agree it makes sense to override it in «gui» application. Maybe it also 
make sense to have this property set to true in debug build.

Feel free to submit a patch

Ivan

> 7 апр. 2020 г., в 21:08, Alberto Mardegan  
> написал(а):
> 
> Hi there!
>  I've recently built a Windows application with QBS, and was a bit
> surprised that it was built as a console application (the terminal
> opened when running it).
> 
> Would anyone object if I submit a change to the QtGuiApplication item,
> so that it unconditionally sets the `consoleApplication` property to false?
> 
> Ciao,
>  Alberto
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] How to setup: QtC, Qbs, Clang on Windows

[Иван Комиссаров]

There’s also no such property, there’s cpp.compilerName. Are you sure you’re 
not using «qbs.compilerName» in your project somewhere?

Ivan

> 27 марта 2020 г., в 18:58, Иван Комиссаров  написал(а):
> 
> Hello, what version of QtC / qbs / LLVM are you using?
> 
> Ivan
> 
>> 27 марта 2020 г., в 18:20,  
>>  написал(а):
>> 
>> I have been struggling with setting up Qbs inside Qt Creator so it uses 
>> clang-cl on Windows. On the command line it is auto-detected and works just 
>> fine. In QtC I need to add manually compilers for C and C++, both set to 
>> clang-cl.exe (in c:/program files/llvm/bin). Then I add new Kit and specify 
>> these compilers. All seems fine. QtC also adds new profile in Qbs section 
>> with data identical to those auto-detected on the command line. So again, 
>> seems fine. But it still does not work, the error:
>> 
>> warning: Error: TypeError: Result of expression 'qbs.compilerName' 
>> [undefined] is not an object.
>> 
>> And yet the compilerName is indeed set correctly in the profile. Is it a bug 
>> in QtC? Or am I doing something wrong?
>> 
>> Thanks!
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 

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

Re: [Qbs] How to setup: QtC, Qbs, Clang on Windows

[Иван Комиссаров]

Hello, what version of QtC / qbs / LLVM are you using?

Ivan

> 27 марта 2020 г., в 18:20,  
>  написал(а):
> 
> I have been struggling with setting up Qbs inside Qt Creator so it uses 
> clang-cl on Windows. On the command line it is auto-detected and works just 
> fine. In QtC I need to add manually compilers for C and C++, both set to 
> clang-cl.exe (in c:/program files/llvm/bin). Then I add new Kit and specify 
> these compilers. All seems fine. QtC also adds new profile in Qbs section 
> with data identical to those auto-detected on the command line. So again, 
> seems fine. But it still does not work, the error:
>  
> warning: Error: TypeError: Result of expression 'qbs.compilerName' 
> [undefined] is not an object.
>  
> And yet the compilerName is indeed set correctly in the profile. Is it a bug 
> in QtC? Or am I doing something wrong?
>  
> Thanks!
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Building code generator and its dependencies for a different architecture than the rest of the products

[Иван Комиссаров]

Ah, never mind, you should not since you’re not inheriting the project.profile

> 20 марта 2020 г., в 19:53, Иван Комиссаров  написал(а):
> 
> This looks like a bug - this property is not set in Profile item context.
> 
> Shouldn't you also set qbs.architecture to «x86_64» in the hostProfile ?
> 
>> 20 марта 2020 г., в 17:01, Leon Buckel > <mailto:leon.buc...@clausmark.com>> написал(а):
>> 
>> Here's a small test project I set up that has the issue. Note that I have to 
>> set qbs.targetPlatform to "macos" because qbs.hostPlatform is undefined. The 
>> docs only say 'Do not use this property'.
> 

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

Re: [Qbs] Building code generator and its dependencies for a different architecture than the rest of the products

[Иван Комиссаров]

This looks like a bug - this property is not set in Profile item context.

Shouldn't you also set qbs.architecture to «x86_64» in the hostProfile ?

> 20 марта 2020 г., в 17:01, Leon Buckel  написал(а):
> 
> Here's a small test project I set up that has the issue. Note that I have to 
> set qbs.targetPlatform to "macos" because qbs.hostPlatform is undefined. The 
> docs only say 'Do not use this property'.

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

Re: [Qbs] Using QBS with an nonexistent $HOME

[Иван Комиссаров]

That’s a very interesting article!

However, I’ve noticed a strange thing.

The doc [0] says that CPPFLAGS variable is the "Options for the C preprocessor» 
which means this variable should map to cpp.cppFlags, not to 
cpp.commonCompilerFlags
This also means that duplicated values passed as cpp.cFlags and cpp.cxxFlags 
could be passed once as cpp.commonCompilerFlags (with the assumption that 
Debian applications don't use ObjectiveC a lot)

[0] https://manpages.debian.org/testing/dpkg-dev/dpkg-buildflags.1.en.html 


Regarding profiles - strictly speaking, they are not mandatory, if gcc/clang 
can be found in PATH, one can build by simply invoking «qbs build 
qbs.toolchainType:gcc» / «qbs build qbs.toolchainType:clang» respectively (and 
passing all options on the command line). The first invocation is the same as 
«qbs build» on Linux since qbs.toolchainType is «gcc» on Linux by default. 
However, profiles might be an easier way to do a setup, your approach with 
«debian» profile is OK too - profiles are simply a «bag» of properties and are 
designed to avoid huge command line invocations

Regarding clean rule - what if we add an extra option to qbs clean like «qbs 
clean --all» that will remove the *.bg file (build graph) as well? Will that be 
more convenient?

> 29 февр. 2020 г., в 17:17, Wookey  написал(а):
> 
> On 2020-02-29 09:05 +0300, Alberto Mardegan wrote:
> 
> I have written a wiki page about using QBS to build debian packages:
> https://wiki.debian.org/Qbs 
> 
> I deal with QBS's desire to store a profile in the home directory by setting
> --settings-dir to either /tmp (potential security risk as other can change 
> your build/config) or --settings-dir $(CURDIR)/debian for package builds.

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

Re: [Qbs] Using QBS with an nonexistent $HOME

[Иван Комиссаров]

Hello!

Have you tried the --settings-dir option to some existent (maybe temporary) 
directory? I can’t test it as I don’t have Qbs 1.10, but it should help.

Ivan

> 29 февр. 2020 г., в 09:05, Alberto Mardegan  
> написал(а):
> 
> Hi there!
>  I'm trying to build a Debian/Ubuntu package of a QBS project in
> launchpad.net; the site uses sbuild, which has the peculiarity of
> setting "HOME=/sbuild-nonexistent".
> 
> I'm stuck at the step "qbs setup-qt", which fails with this error:
> 
> Setting up Qt profile 'qt5' failed: Cannot create directory
> '/sbuild-nonexistent/.config/QtProject/qbs/1.10.1/profiles/qt5/modules/Qt'.
> 
> Adding the "--system" option to QBS doesn't seem to help. I guess I
> could workaround the issue by setting HOME=$PWD, but this partially
> defeats the point of using sbuild.
> 
> Is there a better way to solve this? I'm especially curious, because the
> step "setup-toolchains" doesn't seem to be affected by this issue.
> 
> Ciao,
>  Alberto
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] (no subject)

[Иван Комиссаров]

https://bugreports.qt.io/browse/QBS-1522

> 29 нояб. 2019 г., в 08:03, Dan Pat  написал(а):
> 
> > Who imposes that requirement and why?
> Ok. Here's the thing. The project I am working on is based on Qt library and 
> consists of a bunch of libraries and executables with dependencies between 
> them expressed via a "Depends" language item. Plus there a number of 
> pre-built third-party libraries wrapped in Modules that some of the Products 
> within the project depend on. The project compiles and links and I can run 
> the executables just fine. Now comes Asan. We use a dynamic version of Asan, 
> since the CRT we use is dynamic (compilation with /MD option) . The first 
> step was to compile the project with sanitiser support. I managed that, but I 
> when tried to to run one of the tests, Asan reported an error. I did a bit of 
> research and figured out that the error was detected early on during 
> initialization of Qt DLLs. From what I have been able to find out from 
> Internet sources and through a  bit of testing I concluded that for the 
> sanitizer to work properly, the asan.dll must be loaded before any other DLL 
> in the process, specifically before the C runtime library, because it needs 
> to do some hotpatching in order to be able trace every heap allocation call. 
> In my case, seemingly, the asan.dll was loaded somewhere in the middle of the 
> DLL loading sequence when some of the heap allocation has already been done 
> resulting in a false error report. My research revealed that in order for the 
> asan.dll to be loaded first, its import record in the binary IAT must come 
> first, and for the import record to come first the corresponding import 
> library must come first on the linker's list of imports. The asan library is 
> contained in a Module, and I have no idea how to get its import to the 
> beginning of the linker's list. Let's consider an example Product. Looking at 
> an issued linker command:  Module dependencies are listed after any Product 
> dependencies, any libraries specified directly in cpp.dynamicLibraries (as an 
> experiment, we  normally use Depends) come before Module dependencies but 
> after any Product dependencies, any cpp,linkerFlags (tried as a last resort) 
> go the end of the linker's arguments string.  I hope I have made myself 
> clear, thank you. 
> 
> чт, 28 нояб. 2019 г. в 21:37, Иван Комиссаров  <mailto:abba...@gmail.com>>:
> It’s worth mentioning, that compiling with verbose flag can give some insight 
> on what libraries/options clang-cl passes to the linker:
> 
> clang-cl -v -fsanitize=address main.cpp
> 
> Иван Комиссаров
> 
>> 28 нояб. 2019 г., в 17:23, Иван Комиссаров > <mailto:abba...@gmail.com>> написал(а):
>> 
>> I did a small research and was able to compile a small example with 
>> clang-cl and asan.
>> Here are the flags I had to set manually:
>> 
>> cpp.optimization: "none"
>> cpp.cxxFlags: [
>> "/MT",
>> "-fsanitize=address",
>> ]
>> cpp.linkerFlags: [
>> 
>> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
>> 
>> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
>> ]
>> cpp.staticLibraries: [
>> 
>> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
>> 
>> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
>> ]
>> 
>> Probably, we should add some support for that in Qbs...
>> The problem is that qbs calls the linker directly (which is not the same 
>> clang-cl uses), maybe it’s worth using clang-cl for linking... or just add 
>> support for the usual clang with msvc ABI (I have plans for that for 1.16)
>> 
>> Иван Комиссаров
>> 
>>> 28 нояб. 2019 г., в 15:53, Christian Kandeler >> <mailto:christian.kande...@qt.io>> написал(а):
>>> 
>>> On Thu, 28 Nov 2019 18:58:54 +0500
>>> Dan Pat mailto:danni...@gmail.com>> wrote:
>>> 
>>>> Hello. I am trying to use Asan in my project (windows 10, clang-cl).
>>>> There's a requirement for the Asan import library to appear first in the
>>>> linker's list of import libraries. 
>>> 
>>> Who imposes that requirement and why?
>>> 
>>>> I cannot seem to find a way to achieve this with qbs. Any suggestions?
>>> 
>>> If you are sure it's really, really needed, you 

Re: [Qbs] (no subject)

[Иван Комиссаров]

Hello, Dan!

It’s very sad to hear that QtC crashes for you.

There’s one known issue in qbs which will be fixed with QtC 4.11 release. Can 
you please try release candidate if it works better or not? 
https://download.qt.io/development_releases/qtcreator/4.11/4.11.0-rc1/

If release candidate still crashes, it might be worth compiling QtCreator 
manually in release with debug info - in that case, you will be able to attach 
a post-mortem debugger to it and see what happens

PS: I am experiencing crashes on MacOS with QtC 4.10, but they are not related 
to qbs as far as I can see from the backtrace.

> 2 дек. 2019 г., в 07:55, Dan Pat  написал(а):
> 
> Hello, my qtcreator keeps crashing during reparsing of qbs projects (windows 
> 10) - like twice or thrice a day. I'd really like to provide something along 
> the lines of a log or a backtrace. Does such a log exist? AFAIK, to get a 
> meaningfull backtrace for release builds under windows some sort of a 
> backtrace creation facility has to be used. Does qtcreator/qbs have one in 
> place?  
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] (no subject)

[Иван Комиссаров]

It’s worth mentioning, that compiling with verbose flag can give some insight 
on what libraries/options clang-cl passes to the linker:

clang-cl -v -fsanitize=address main.cpp

Иван Комиссаров

> 28 нояб. 2019 г., в 17:23, Иван Комиссаров  написал(а):
> 
> I did a small research and was able to compile a small example with clang-cl 
> and asan.
> Here are the flags I had to set manually:
> 
> cpp.optimization: "none"
> cpp.cxxFlags: [
> "/MT",
> "-fsanitize=address",
> ]
> cpp.linkerFlags: [
> 
> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
> 
> "-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
> ]
> cpp.staticLibraries: [
> 
> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",
> 
> "C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
> ]
> 
> Probably, we should add some support for that in Qbs...
> The problem is that qbs calls the linker directly (which is not the same 
> clang-cl uses), maybe it’s worth using clang-cl for linking... or just add 
> support for the usual clang with msvc ABI (I have plans for that for 1.16)
> 
> Иван Комиссаров
> 
>>> 28 нояб. 2019 г., в 15:53, Christian Kandeler  
>>> написал(а):
>>> 
>> On Thu, 28 Nov 2019 18:58:54 +0500
>> Dan Pat  wrote:
>> 
>>> Hello. I am trying to use Asan in my project (windows 10, clang-cl).
>>> There's a requirement for the Asan import library to appear first in the
>>> linker's list of import libraries. 
>> 
>> Who imposes that requirement and why?
>> 
>>> I cannot seem to find a way to achieve this with qbs. Any suggestions?
>> 
>> If you are sure it's really, really needed, you can use a Properties item in 
>> your product with e.g. cpp.dynamicLibraries 
>> (https://doc.qt.io/qbs/qml-qbslanguageitems-properties.html#overrideListProperties-prop),
>>  but then you will have to list *all* libraries there.
>> 
>> 
>> Christian
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] (no subject)

[Иван Комиссаров]

I did a small research and was able to compile a small example with clang-cl 
and asan.
Here are the flags I had to set manually:

cpp.optimization: "none"
cpp.cxxFlags: [
"/MT",
"-fsanitize=address",
]
cpp.linkerFlags: [

"-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",

"-wholearchive:C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
]
cpp.staticLibraries: [

"C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan-x86_64.lib",

"C:\\Developer\\LLVM\\lib\\clang\\8.0.0\\lib\\windows\\clang_rt.asan_cxx-x86_64.lib",
]

Probably, we should add some support for that in Qbs...
The problem is that qbs calls the linker directly (which is not the same 
clang-cl uses), maybe it’s worth using clang-cl for linking... or just add 
support for the usual clang with msvc ABI (I have plans for that for 1.16)

Иван Комиссаров

> 28 нояб. 2019 г., в 15:53, Christian Kandeler  
> написал(а):
> 
> On Thu, 28 Nov 2019 18:58:54 +0500
> Dan Pat  wrote:
> 
>> Hello. I am trying to use Asan in my project (windows 10, clang-cl).
>> There's a requirement for the Asan import library to appear first in the
>> linker's list of import libraries. 
> 
> Who imposes that requirement and why?
> 
>> I cannot seem to find a way to achieve this with qbs. Any suggestions?
> 
> If you are sure it's really, really needed, you can use a Properties item in 
> your product with e.g. cpp.dynamicLibraries 
> (https://doc.qt.io/qbs/qml-qbslanguageitems-properties.html#overrideListProperties-prop),
>  but then you will have to list *all* libraries there.
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] A simple project that copy an executable does not work

[Иван Комиссаров]

I guess, documentation is updated manually as a part of the release process 
(which did not happen yet AFAIK).
Christian should know better, he is the maintainer:)
I hope that some day when we will have a proper CI for Qbs, we can update doc 
on a daily basis

Иван Комиссаров

> 9 авг. 2019 г., в 4:42, Vincent Hui  написал(а):
> 
> Hi Ivan,
> 
> Do you know why the document for Rule is not updated? Your commit was merged, 
> am I right?
> https://doc-snapshots.qt.io/qbs/qml-qbslanguageitems-rule.html
> 
> Thank you again for making a complete example for Rule.
> 
> br,
> Vincent
> 
> 
>> On Sat, 6 Jul 2019 at 23:15, Иван Комиссаров  wrote:
>> https://codereview.qt-project.org/c/qbs/qbs/+/267333
>> 
>> > 6 июля 2019 г., в 15:51, Иван Комиссаров  написал(а):
>> > 
>> > Ivan.
>> 
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Qbs (way) faster than cmake (or benchmark issue)

[Иван Комиссаров]

Yeah, blog post would be nice. I'd wait for the product graph feature though so 
we could compare cmake buildgraph and Qbs build graphs as well.

Иван Комиссаров

> 23 июля 2019 г., в 4:49, Vincent Hui  написал(а):
> 
> Hi Chris,
> 
> Thank you for your benchmark.
> 
> Would you mind writing a blog post to record your benchmark in order to 
> promote Qbs?
> 
> By the way, I think we need to come up with good ideas for promoting Qbs.
> 
> Vincent
> 
> 
>> On Tue, 23 Jul 2019 at 07:31, Christian Gagneraud  wrote:
>> On Mon, 22 Jul 2019 at 22:10, Oswald Buddenhagen
>>  wrote:
>> >
>> > On Mon, Jul 22, 2019 at 11:00:07AM +1200, Christian Gagneraud wrote:
>> > > At the 20 jobs mark, cmake start to stagnate, whereas qbs still make
>> > > use of parallelism, at the 30 jobs mark, cmake completely stopped
>> > > reducing overall build time, whereas qbs start to stagnate. At the 40
>> > > jobs mark, both systems are stale.
>> > >
>> > that means that qbs creates a build graph with fewer bottlenecks. cmake
>> > certainly could do that with relatively little effort as well, at the
>> > likely cost of slightly increased null rebuild times (due to the graph
>> > being bigger).
>> 
>> Should i plot qbs vs cmake null rebuild times? That would be funny if
>> qbs was faster again... :P
>> 
>> Just kidding...
>> 
>> I think the build graph generated by cmake is too big/complex.
>> By default, Qbs doesn't track dependencies on system header files for 
>> example.
>> 
>> We shouldn't see such a big difference b/w cmake/ninja and qbs.
>> Although i like Qbs very much, i do not believe that it implements
>> revolutionary algorithms compared to ninja.
>> Ninja website is actually very interesting (eg. w/ references to
>> http://gittup.org/tup/ and https://github.com/apenwarr/redo) and my
>> gut feeling is that this tool is really efficient in executing it's
>> input.
>> 
>> I think (on of) the problem is what cmake generates, as mentioned in
>> an earlier email, I find suspicious that ninja has to call cmake to
>> handle moc. And this moc aggregation is certainly one of the
>> bottleneck (again, just gut feelings).
>> 
>> > some suggestions for making a diagram where the interesting stuff isn't
>> > crammed into a narrow strip at the bottom:
>> > - a logarithmic job count axis
>> 
>> Doesn't really help on it's own, but log on both axes kind of do, see
>> attached document.
>> 
>> > - build speed per job vs. job count
>> > - cpu utilization per core vs. job count
>> 
>> The main issue here is that i've used '-j' to control jobs, which is
>> not good, i should have used docker --cpus instead.
>> Nonetheless all the data is attached if someone fancy some data mining.
>> 
>> > - 
>> 
>> I don't think i'll spend more time on this. But feel free to play with
>> that if you (or anyone else) want.
>> https://gitlab.com/chgans/cubicninjas
>> 
>> Nothing fancy really, it's just a Dockerfile and a build script.
>> 
>> I've attached the csv files, there's lot of potentially interesting
>> data in build-qtcreator-stats.csv (see
>> https://linux.die.net/man/1/time, i've dumped everything)
>> The other file (build-qtcreator-dstat.csv) is data collected by dstat
>> for the whole duration of the builds (see
>> https://linux.die.net/man/1/dstat, i've dumped disk, load and cpu
>> data).
>> Again, it's full of potential useful data, it just needs some mining...
>> 
>> Docker command:
>> cd /path/to/qt-creator
>> git clone https://gitlab.com/chgans/cubicninjas.git
>> docker build -t cubicninjas cubicninjas
>> mkdir builds
>> docker run -it -v $PWD:$PWD -w $PWD --mount
>> type=tmpfs,destination=/tmp --mount type=tmpfs,destination=$PWD/builds
>> cubicninjas $PWD/cubicninjas/build.sh
>> 
>> basic gnuplot command for build-qtcreator-stats.csv:
>> set datafile separator ","
>> set logscale x
>> set logscale y
>> plot 'build-qtcreator-stats.csv' every 2::1 using 2:19 with
>> linespoints title 'ninja', '' every 2::0 using 2:19 with linespoints
>> title 'qbs'
>> 
>> Enjoy and my apologies for the grumpy email yesterday.
>> 
>> Chris
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] How to check whether a project is a subproject of another project?

[Иван Комиссаров]

You can make two top-level projects, something like «my lib-standalone.qbs» 
which includes «mylib.qbs» and setups the properties to enable tests/whatever. 
All what you don’t want for users is disabled by default.

> 20 июля 2019 г., в 6:27, Vincent Hui  написал(а):
> 
> Hi Christian,
> 
> Thank you very much for your reply.
> 
> I am sorry for not stating my question clearly. Perhaps I should use 
> isStandalone instead of isSubProject, my motivation is to facilitate users of 
> my libraries which are stored in individual git repository. The main product 
> of my qbs project is a library, other products are examples and tests.
> 
> To reduce build time for whole source tree, I prefer examples and tests of my 
> project are not built if my qbs project is not a standalone project. That 
> means my qbs project is added by other projects as a git module. To save time 
> and code of users of my projects, I prefer users of my projects do not need 
> to override properties of my qbs project in order not to build examples and 
> tests. Therefore I need a property to know whether my qbs project is a 
> standalone project.
> 
> By the way, why path is undocumented? Is it because path is private? Why not 
> make it public? Should path be renamed? path being a property name 
> (https://github.com/qbs/qbs/blob/master/src/lib/corelib/buildgraph/buildgraph.cpp#186
>  
> 
>  line#186) and a type name is a bit confusing I think.
> 
> Thank you again,
> Vincent
> 
> 
> On Thu, 18 Jul 2019 at 00:08, Christian Kandeler  > wrote:
> On Wed, 17 Jul 2019 23:25:49 +0800
> Vincent Hui mailto:vincenthk...@gmail.com>> wrote:
> 
> > I want to check whether a project is a subproject of another project. If a
> > project is not a subproject, its examples and tests are built. If a project
> > is a subproject, its examples and tests are not built.
> 
> Declare a property in your project that controls this. Override this property 
> from the containing project. Done.
> 
> > It seems that the method for checking whether a project is a subproject is
> > undocumented.
> 
> There is no such method, and I don't think it would be a good idea to have it.
> 
> > I came up with a method to check whether a project is a subproject. It is
> > checking whether  sourceDirectory is equal to path. I tried a simple
> > project, my method works.
> > 
> > "
> > Project {
> > readonly property bool isSubProject: (sourceDirectory === path) ? false
> > : true;
> > ..
> > "
> > 
> > Can my method work in complicated projects?
> 
> No. The parent project could be in the same directory.
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org 
> https://lists.qt-project.org/listinfo/qbs 
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] [RFC] Add a clang-format config file to qbs repo

[Иван Комиссаров]

Never used clang-format before, but +1.
I don't want waste my time searching for those long lines too=)

Иван Комиссаров

> 8 июля 2019 г., в 11:39, Christian Gagneraud  написал(а):
> 
> Hi there,
> 
> I would like to propose to add a clang-format config file to qbs repo.
> I don't want to go in depth about which coding style we should use, so
> i propose we simple copy the one used by QtCreator developers. :)
> 
> The rational for using clang-format is that it simplifies code review,
> no need to waste time for coding style any more (line too long, white
> space in the wrong place, ...). Any modern IDE will pick it up
> automatically and format your changes according to it.
> 
> If you're interested, it is as well possible to add client side hooks
> that will automatically reformat *only the edited part of files* of
> the commit.
> 
> Before you say Ya/Na, i would like to give some pros and cons (again
> won't go into details):
> - cons: It's rigid, if the config file is "wrong", doesn't understand
> edge cases, is not contextual enough, ... then you just have to deal
> with it (read: accept its rules).
> - pros: say bye-bye to the need to comment (or address comment) about
> indentation, spaces, bracket placement, ... and the need to manually
> check if you do the right thing or not. Let SW do the hard job.
> 
> We've switched to that at work a year or 2 ago, and since then,
> reviews are more focus, it made a huge difference.
> 
> Let me vote first, :)
> +1
> 
> Any comment, objection?
> 
> Chris
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] A simple project that copy an executable does not work

[Иван Комиссаров]

No, this is not possible. The reason is that in common case those products 
(applications, libraries) will diverge in some way. For example, you might want 
to use different resources - icons (you probably do not want to name them 
icon1.png and icon2.png, right?), .desktop entires on Linux, plist files on Mac…

However, you might want to share some properties among those applications - 
that can be achieved via inheritance - you inherit the CppApplication item in a 
file, say, MyApplication.qbs, specify common properties (cpp.cxxFlags, 
cpp.cxxLanguageVersion, etc…) and then instantiate MyApplication and only 
specify only what’s different (files: «main1.cpp» and files: «main2.cpp» in 
your case). That way you don’t need to write all that boilerplate code over and 
over again.

> 7 июля 2019 г., в 15:58, Vincent Hui  написал(а):
> 
> Hi Ivan,
> 
> Thank you very much for creating a complete example in Rule document. That 
> definitely helps new qbs users.
> 
> I have another question that I didn't find answers after reading qbs doc.
> 
> Is it possible to create CppApplication dynamically to generate multiple 
> executables?
> 
> For example, I have two cpp files "main1.cpp" "main2.cpp" containing one main 
> functions respectively inside "apps" folders. I want my project can add all 
> cpp files automatically can build all executables "main1.exe" "main2.exe" 
> respectively.
> 
> I know I can add all cpp files automatically by using Group. However, I don't 
> know how to build 2 executables without hardcode 2 CppApplication.
> 
> Thank you again,
> Vincent
> 
> 
> On Sat, 6 Jul 2019 at 23:15, Иван Комиссаров  <mailto:abba...@gmail.com>> wrote:
> https://codereview.qt-project.org/c/qbs/qbs/+/267333 
> <https://codereview.qt-project.org/c/qbs/qbs/+/267333>
> 
> > 6 июля 2019 г., в 15:51, Иван Комиссаров  > <mailto:abba...@gmail.com>> написал(а):
> > 
> > Ivan.
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org <mailto:Qbs@qt-project.org>
> https://lists.qt-project.org/listinfo/qbs 
> <https://lists.qt-project.org/listinfo/qbs>

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

Re: [Qbs] A simple project that copy an executable does not work

[Иван Комиссаров]

https://codereview.qt-project.org/c/qbs/qbs/+/267333

> 6 июля 2019 г., в 15:51, Иван Комиссаров  написал(а):
> 
> Ivan.

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

Re: [Qbs] A simple project that copy an executable does not work

[Иван Комиссаров]

Yes, Qbs doc is a bit incomplete and contains some confusing and misleading 
examples.

I even failed to answer your question myself. Well, I understood the reason 
correctly (there’s no dependent product), but failed to provide a working 
example in reasonable time.

Feel free to create tickets (or even provide patch sets) for the doc - I (we?) 
will try to improve what’s unclear. I personally learned Qbs by looking at the 
QtCreator source code (which is not user friendly, but there were almost no doc 
in 2013) so it is not very clear for me which parts of the doc are 
missing/incomplete/misleading. However, the doc is very important as it’s what 
users see.

Your feedback is welcome!

Ivan.

> 6 июля 2019 г., в 15:29, Vincent Hui  написал(а):
> 
> Hi Richard,
> 
> Thank you very much for your reply. 
> 
> I am creating toy projects for learning how to use qbs.
> 
> In the document of Rule, A simple example is not a complete example. It does 
> not tell user to assign the product type to "txt_output" explicitly.
> 
> I hope the document can be improved in the future.
> 
> Thank you again,
> Vincent
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] How do I use Parameter property in a module itself?

[Иван Комиссаров]

However, this is an interesting question.
Is it true that all module properties should be allowed to be set per-file?

 Product {
  Depends { name: "mymodule"; }
  mymodule.useFeature: true // enable some probes here, do heavy checks

  Group { files: «file»;  mymodule.useFeature: false; } // does nothing, 
all checks are already done
  }

What worse, this won’t work at all:

 Product {
  Depends { name: "mymodule"; }
  Group { files: «file»;  mymodule.useFeature: true; } // ooops
  }

> 10 июня 2019 г., в 20:45, Иван Комиссаров  написал(а):
> 
> Yes, I’d like to have some syntax sugar here.
> But 2-liner is probably OK too.
> 
>> 10 июня 2019 г., в 20:32, Richard Weickelt  написал(а):
>> 
>> Ivan,
>> 
>> Do you actually want to achieve this?
>> 
>>   Module {
>>   property bool useFeature: false
>> 
>>   Probes.BinaryProbe {
>>   condition: useFeature
>>   }
>>   }
>> 
>>   Product {
>>   Depends { name: "mymodule"; }
>>   mymodule.useFeature: true
>>   }
>> 
>> The Parameter item, as far as I understand it, makes only sense if you have
>> - 2 products A and B
>> - B depends on A and on mymodule
>> - in the context of B you want to control, how a module "mymodule"
>> handles A
>> 
>> You wouldn't use it to just parameterize "mymodule", because that can be
>> achieved with plain properties.
>> 
>> The probably best explanation so far of the Parameter item can be found in
>> the following blog post:
>> https://blog.qt.io/blog/2017/09/05/qbs-1-9-released/ I realize that the
>> reference documentation of the Parameter item is insufficient and the
>> example in the module documentation could be more sensible.
>> 
>> Richard
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 

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

Re: [Qbs] How do I use Parameter property in a module itself?

[Иван Комиссаров]

Yes, I’d like to have some syntax sugar here.
But 2-liner is probably OK too.

> 10 июня 2019 г., в 20:32, Richard Weickelt  написал(а):
> 
> Ivan,
> 
> Do you actually want to achieve this?
> 
>Module {
>property bool useFeature: false
> 
>Probes.BinaryProbe {
>condition: useFeature
>}
>}
> 
>Product {
>Depends { name: "mymodule"; }
>mymodule.useFeature: true
>}
> 
> The Parameter item, as far as I understand it, makes only sense if you have
> - 2 products A and B
> - B depends on A and on mymodule
> - in the context of B you want to control, how a module "mymodule"
>  handles A
> 
> You wouldn't use it to just parameterize "mymodule", because that can be
> achieved with plain properties.
> 
> The probably best explanation so far of the Parameter item can be found in
> the following blog post:
> https://blog.qt.io/blog/2017/09/05/qbs-1-9-released/ I realize that the
> reference documentation of the Parameter item is insufficient and the
> example in the module documentation could be more sensible.
> 
> Richard
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

[Qbs] How do I use Parameter property in a module itself?

[Иван Комиссаров]

I’d like to do something like this:

Module {
Parameter { property bool useFeature: false }

Probes.BinaryProbe {
condition: useFeature
}
}

So I’d be able to write:

Depends { name: "mymodule"; useFeature: true; }






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

Re: [Qbs] Install/Depends resolution changed from qbs 1.12.2 to qbs 1.13.0?

[Иван Комиссаров]

Funny fact, but Qbs tests on were failing on macOS because of this change:)
However, I am not sure that we should roll it back, we can break something 
*again*
The original motivation for this change is that Qbs used to misinterpret 
install-root and install-prefix paths. Now it is consistent with other build 
systems:
install-root/install-prefix/your/directory/structure

The reason is that prefix may be hardcoded in the binary like it is done for 
qmake and setting install-root to /usr/local is wrong, install-root should be /.
Well, yes, in most cases, when app is portable it doesn't make any difference 
so I understand that change is annoying (I was the one who could not run tests 
on macOS)

But the doc should be updated...

Иван Комиссаров

20 мая 2019 г., в 9:01, Richard Weickelt  написал(а):

>> Oh yeah, it has been an unsatisfying surprise that default installation
>> prefix changed from empty string to "usr/local/" on Linux. All builds
>> are broken, all scripts working on the results are broken. Not
>> hardcoding is not an option when it comes to CI integration etc.
>> 
>> Next time I will be happy if such a change is announced in capital
>> letters.
> 
> This was also an unpleasant surprise for me. Note that
> https://doc.qt.io/qbs/qml-qbsmodules-qbs.html#installPrefix-prop does not
> reflect this change. Thus, instead of going over the docs, I'd rather like
> to set installPrefix back to undefined on all platforms for Qbs 1.13.1.
> 
> Anything that speaks against that?
> 
> Richard
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

In many cases, you don’t need to copy them. For trivial getters, you can return 
const-ref/span to the internal vector instead of a copy because in many places 
all we do is iterate over that vector.

The only argument for copies is that it’s impossible to change the 
implementation from returning a member to some «transformed member» without 
breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t think 
it’s relevant.

This will save us from creating a temp variables or usages of qAsCont to avoid 
detaching in range-for loops (see this commit 
https://codereview.qt-project.org/#/c/253792/ 
<https://codereview.qt-project.org/#/c/253792/> to estimate the amount of 
incorrect usages of Qt containers). Note, that those clutter API as well, 
especially the need of a temp variable.

I didn’t do any measurements, but quick search for QList in Qbs source code 
shows a lot of places  where it’s used incorrectly - it stores «big» 
structures, std::shared_pointers, even all QSharedDataPointer classes are not 
marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists…

My point is - current usage of Qt containers in Qbs should be carefully 
revisited, switching to more suitable containers (QVector or 
std::vector/std::deque).


> 16 мая 2019 г., в 0:00, Christian Gagneraud  написал(а):
> 
> On Thu, 16 May 2019 at 09:32, Иван Комиссаров  wrote:
>>> 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
>>> 
>>> Getting rid of implicitly shared containers should be a rather obvious move
>>> when "performance" is part of any "final picture", coherent or not.
>> 
>> +1 from me, hidden detaches are evil =)
> 
> How do you avoid copy then? Without cluttering an API.
> 
> Chris

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

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

+1 from me, hidden detaches are evil =)

> 15 мая 2019 г., в 19:50, André Pönitz  написал(а):
> 
> Getting rid of implicitly shared containers should be a rather obvious move
> when "performance" is part of any "final picture", coherent or not.
> 
> Andre'
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

___
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?

[Иван Комиссаров]

Interesting. Any idea why Qbs is so slow with ccache?

Иван Комиссаров

> 15 мая 2019 г., в 17:29, Orgad Shaneh  написал(а):
> 
> du -shc build-qtc-qbs
> 15G build-qtc-qbs
> 15G total
> du -shc build-qtc-cmake
> 4.0Gbuild-qtc-cmake
> 4.0Gtotal
> 
> The number of jobs is default. For qbs it's 40, ninja uses 42.
> 
> I tried again without autotests, as Christian suggested:
> 
> time qbs -f ../qt-creator/qtcreator.qbs profile:qt-5-11-1 
> modules.cpp.compilerWrapper:ccache project.withAutotests:false
> cold ccache:
> real4m58.383s
> user114m45.623s
> sys 15m38.866s
>  
> warm cache:
> real1m20.800s
> user16m20.307s
> sys 3m57.194s
>  
> time cmake ../qt-creator -DCMAKE_CXX_COMPILER_LAUNCHER=ccache 
> -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_BUILD_TYPE=Debug -G Ninja
> real0m8.256s
> user0m7.425s
> sys 0m0.827s
>  
> time ninja
> cold cache:
> real5m23.413s
> user128m25.457s
> sys 16m11.551s
>  
> time ninja:
> warm cache:
> real0m45.964s
> user7m12.563s
> sys 2m23.616s
> 
> 
>> On Wed, May 15, 2019 at 5:50 PM Vincent Hui  wrote:
>> How many number of threads were used? Is the number of threads used by Qbs 
>> equal to the number of threads used by CMake? 
>> 
>> 
>>> On Wed, 15 May 2019 at 22:11, Christian Kandeler  
>>> wrote:
>>> On Thu, 16 May 2019 02:01:21 +1200
>>> Christian Gagneraud  wrote:
>>> 
>>> > As well, please note that the current CMake doesn't build as much
>>> > stuff as the qbs one. Not sure the difference is huge, but you need to
>>> > compare "equal jobs".
>>> 
>>> For instance, all autotests are missing from the cmake build, so this
>>> alone accounts for a difference of ~100 products. You need to set
>>> "project.withAutotests:false" when building with qbs.
>>> 
>>> 
>>> Christian
>>> ___
>>> Qbs mailing list
>>> Qbs@qt-project.org
>>> https://lists.qt-project.org/listinfo/qbs
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] External Dependencies

[Иван Комиссаров]

Application should not be aware about this property at all, this is a hardcoded 
_module_ property (similar to priority), this is just a way to modify the way 
how modules are loaded.

> 14 мая 2019 г., в 23:54, NIkolai Marchenko  
> написал(а):
> 
> Unfortunately I still don't see how or where the chain of dependencies on 
> DarwinGCC and GenericGCC  is being set up. Will it be in zlib module ?
> I am trying to understand how will the application know what is the 
> "recovery" option and when to consider all recovery paths exhausted and can't 
> bc I do not see any external linking between those in the examples

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

Re: [Qbs] External Dependencies

[Иван Комиссаров]

Let me use Cpp module as example.
We have macos-gcc.qbs:
  
DarwinGCC {
priority: 1
condition: qbs.targetOS.contains('macos') &&
   qbs.toolchain && qbs.toolchain.contains('gcc')
}

And we have UnixGCC.qbs:

GenericGCC {
priority: -50
condition: qbs.toolchain && qbs.toolchain.contains("gcc")
}

Both conditions are true on macOS, so we will try loading only macos-gcc since 
it has higher priority.
If loading it fails, we’re done here (which is perfectly reasonable for the cpp 
module), we won’t try loading UnixGCC.

I suggest adding something like

DarwinGCC {
recover: true
}

So Qbs will try to load next module with lower priority (UnixGCC).

For real-world example, like zlib, the chain can be like «try pkg-config, if it 
fails, try detecting via probes».

The goal is to have something like this on the client-side:
Depends { name: "zlib"; minimumVersion: "1.2.3.4" }

Not this: 
Depends { name: «zlib.pkgconfig"; minimumVersion: «1.2.3.4»; required: false }
Depends { name: «zlib.probes"; condition: !zlib.pkgconfig.found; 
minimumVersion: «1.2.3.4"; required: false }


> 14 мая 2019 г., в 22:44, NIkolai Marchenko  
> написал(а):
> 
> > by adding property bool recover to the Module which tells Qbs to try 
> > loading next module in a chain
> Probably needs a code example of a proposed solution. What is a "chain" like 
> in this case?
> 
> On Tue, May 14, 2019 at 11:32 PM Иван Комиссаров  <mailto:abba...@gmail.com>> wrote:
>> On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko > <mailto:enmarantis...@gmail.com>> wrote:
>> Wouldn't it be more reasonable to implement something like OptionalDepends 
>> where you could just list all possible dependencies in the order in which it 
>> should be loaded?
>> 
> 
> This doesn’t solve the problem of the boilerplate code, you're suggesting to 
> add some syntax sugar.
> 
> However, it might be useful to specify the order in which 
> probes/pkg-config/whatever are used (or even disable one of them).
> 
> Maybe, this can be done via product/module properties, something like
> 
> products.MyProduct.pkgconfig.condition:false
> 
> There are some corner cases when you’re searching for libs A and B and you 
> want to use pkg-config for lib A and probes for lib B… Not sure if it’s worth 
> supporting that case.
> 
>> 14 мая 2019 г., в 22:14, NIkolai Marchenko > <mailto:enmarantis...@gmail.com>> написал(а):
>> 
>> And while we are on the subject of finding libs. Is it possible to somehow 
>> indicate that a library you are trying to link isn't compatible with the 
>> compiler? Somethe _other_ than "unresolved external" error that can indicate 
>> anything from lib not being where you want it to be, a mistype in the path, 
>> incorrect lib version or, indeed, binary incompatibility. .
>> 
> 
> For pkg-config, I don’t see such feature; it assumes that you’re set up paths 
> so it won’t find wrong lib (paths like sysroot).
> 
> For Qbs itself, LibraryProbe should check for the desired architecture and 
> discard incompatible libraries. I don’t see any problems implementing this.
> It should also have a property to be able to choose between static/dynamic 
> libraries. It’s quite dumb for now, actually=)

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

Re: [Qbs] External Dependencies

[Иван Комиссаров]

> On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko  > wrote:
> Wouldn't it be more reasonable to implement something like OptionalDepends 
> where you could just list all possible dependencies in the order in which it 
> should be loaded?
> 

This doesn’t solve the problem of the boilerplate code, you're suggesting to 
add some syntax sugar.

However, it might be useful to specify the order in which 
probes/pkg-config/whatever are used (or even disable one of them).

Maybe, this can be done via product/module properties, something like

products.MyProduct.pkgconfig.condition:false

There are some corner cases when you’re searching for libs A and B and you want 
to use pkg-config for lib A and probes for lib B… Not sure if it’s worth 
supporting that case.

> 14 мая 2019 г., в 22:14, NIkolai Marchenko  
> написал(а):
> 
> And while we are on the subject of finding libs. Is it possible to somehow 
> indicate that a library you are trying to link isn't compatible with the 
> compiler? Somethe _other_ than "unresolved external" error that can indicate 
> anything from lib not being where you want it to be, a mistype in the path, 
> incorrect lib version or, indeed, binary incompatibility. .
> 

For pkg-config, I don’t see such feature; it assumes that you’re set up paths 
so it won’t find wrong lib (paths like sysroot).

For Qbs itself, LibraryProbe should check for the desired architecture and 
discard incompatible libraries. I don’t see any problems implementing this.
It should also have a property to be able to choose between static/dynamic 
libraries. It’s quite dumb for now, actually=)___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] External Dependencies

[Иван Комиссаров]

I would like to discuss the way how external dependencies should be searched by 
qbs.

While implementing support for the protobuf I found that there several place 
where a generic c++ can come from.

1. It can be detected via pkg-config
2. It can be detected using probes
3. Other pkg-config-like tools? Maybe Vcpkg?
4. It can be the part of the project.

I am not sure if we need to support 4, but if the mechanism of library 
searching will be based on the Depends item, I don’t see why user can’t add a 
«zlib» product that will be fetched prior to system modules. But anyway, that’s 
not the point.

The point is that for now, I have to write stuff like

Depends {
name: "internal.libprotobuf.pkgconfig"
condition: _autoDetect
required: false
}
Depends {
name: "internal.libprotobuf.probes"
condition: _autoDetect && !internal.libprotobuf.pkgconfig.found
required: false
}

Note, that libprotobuf.pkgconfig and libprotobuf.probes are different modules 
in different folders under qbs/modules.
In case I want to add third way to fetch a library, I will require third module 
and third Depends item. Too much boilerplate for a modern build system.

This comes from the limitation that modules are loaded only based on their 
condition and priority and it is not possible to use Probes in conditions. I 
guess, this limitation comes from the fact that probes are heavy to evaluate, 
but I’m not sure.
Either that limitation should be removed, or we can extend the way Qbs loads 
modules by adding property bool recover to the Module which tells Qbs to try 
loading next module in a chain (with lower priority) if loading «best suitable» 
module failed. If the property is false by default, current behavior will be 
preserved and we can use it to implement «chain» loading by simply writing 
Depends { name: "internal.libprotobuf" }. 

Next thing I want to discuss is the way how Qbs should search for libraries 
using Probes. For now, we have IncludeProbe, LibraryProbe and FrameworkProbe 
(for macOS frameworks). It is not very convenient to use them directly, but we 
can wrap them into a ExternalPackage module that provides some input properties 
to tell Probes what to search for:

ExternalPackage {
name: "zlib"
headers: ["zlib.h"]
libraryNames: ["z"]
}

We can also provide some properties to tell Qbs where to search for libraries 
or to override some default behavior:

qbs build modules.ExternalPackage.platformSearchPaths:"/opt/usr/lib" 
modules.ExternalPackage.staticLibs:true

That way, we will have mechanism similar to CMake find package module and we 
can provide support for lot of libraries in a declarative way.

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

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

Good information, thanks.
Qbs itself has a huge dependency on a QtCore, but some stuff is present in 
standard library and can be easily changed to that (we still have enourmous 
amount of places where qlist is used instead of a qvector/std::vector and used 
inefficient); others are trickier but can be bootstrapped (like qfile) if 
needed.
But what about QtScript's dependency on the QtCore/other libs? My point was 
that it may depend on the qtlibs more than Qbs does and the biggest job is 
there, not in Qbs core.

Иван Комиссаров

> 14 мая 2019 г., в 14:08, Christian Gagneraud  написал(а):
> 
>> On Tue, 14 May 2019 at 23:35, Christian Gagneraud  wrote:
>> 
>>> On Tue, 14 May 2019 at 23:11, Christian Gagneraud  wrote:
>>> 
>>>> On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
>>>> 
>>>> I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
>>>> qtdeclarative originally used v8 JavaScript engine which got replaced with 
>>>> Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible 
>>>> to go the opposite direction and remove Qt dependency in the first place?
>>>> Except for GUI and script module, I don't think there's a lot of Qt stuff.
>>> 
>>> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
>>> '*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
>>> | sort | uniq -c | sort -nr
>>>   673 QtCore
>>> 76 QtScript
>>>  7 QtGui
>>>  6 QtWidgets
>>>  5 QtNetwork
>>>  1 QtXml
>> 
>> The above is the number of #include in all cpp and h files, per Qt
>> module. As you can see dependency on QtCore is quite heavy.
>> 
>> And here is the number of cpp/h files using QtScript, per directory:
>> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
>> QtScript src/ | egrep '.(cpp|h)' | xargs dirname | sort | uniq -c |
>> sort -nr
>> 17 src/lib/corelib/buildgraph
>> 14 src/lib/corelib/jsextensions
>> 12 src/lib/corelib/language
>>  3 src/lib/corelib/tools
>> 
>> Ideally you would like to see only jsextensions and language
> 
> Just in case someone follows my monologue... :)
> 
> QtSCript dependency of buildgraph:
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -h
> QtScript src/lib/corelib/buildgraph/ | sed -ne 's,^ *# *include
> *]*\)>.*$,\1,gp' | sort | uniq -c | sort -nr
>10 qscriptvalue.h
>  3 qscriptengine.h
>  3 qscriptcontext.h
>  2 qscriptvalueiterator.h
>  2 qscriptclass.h
>  1 qscriptstring.h
>  1 qscriptprogram.h
>  1 qscriptclasspropertyiterator.h
> 
> I'm no expert at QtScript and Javascript, but this looks mostly like
> "core" classes (value, engine, context, program).
> 
> And here are the "offenders"
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
> QtScript src/lib/corelib/buildgraph/
> src/lib/corelib/buildgraph/artifactsscriptvalue.cpp
> src/lib/corelib/buildgraph/artifactsscriptvalue.h
> src/lib/corelib/buildgraph/buildgraph.cpp
> src/lib/corelib/buildgraph/buildgraph.h
> src/lib/corelib/buildgraph/dependencyparametersscriptvalue.h
> src/lib/corelib/buildgraph/depscanner.cpp
> src/lib/corelib/buildgraph/depscanner.h
> src/lib/corelib/buildgraph/processcommandexecutor.cpp
> src/lib/corelib/buildgraph/projectbuilddata.h
> src/lib/corelib/buildgraph/qtmocscanner.cpp
> src/lib/corelib/buildgraph/qtmocscanner.h
> src/lib/corelib/buildgraph/rulecommands.cpp
> src/lib/corelib/buildgraph/rulecommands.h
> src/lib/corelib/buildgraph/rulesapplicator.cpp
> src/lib/corelib/buildgraph/rulesapplicator.h
> src/lib/corelib/buildgraph/rulesevaluationcontext.h
> src/lib/corelib/buildgraph/scriptclasspropertyiterator.h
> 
> But this is without looking at leaks from langugage itself:
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
> QtScript src/lib/corelib/language/*.h
> src/lib/corelib/language/evaluationdata.h
> src/lib/corelib/language/evaluator.h
> src/lib/corelib/language/evaluatorscriptclass.h
> src/lib/corelib/language/language.h
> src/lib/corelib/language/scriptengine.h
> src/lib/corelib/language/scriptimporter.h
> 
> Is it worth the effort to remove QtScript from buildgraph and make
> language hermetic to QtScript?
> Versus: forking, maintaining (and improving?) QtScript.
> 
> Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
qtdeclarative originally used v8 JavaScript engine which got replaced with 
Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible to go 
the opposite direction and remove Qt dependency in the first place?
Except for GUI and script module, I don't think there's a lot of Qt stuff. 

Иван Комиссаров

> 14 мая 2019 г., в 12:33, Richard Weickelt  написал(а):
> 
> 
>>> However, will this help to get new developers? Right now, there are not that
>>> many contributors.
>> 
>> I agree, how much money do you want to raise? And what for?
>> For now Qbs can use Qt (company/project) infra, so there's no need to
>> manage an infra.
> 
> The Qt Company pays for qt.io. We can ask them to sponsor the domain also in 
> the future, but we cannot expect it.
> 
> If we had fee-lancing contributors, then it might make sense to set up a 
> bounty system. I also find models like this https://www.patreon.com/bjorn 
> interesting. I guess that spare-time contributors have a different motivation 
> though.
> 
> What is IMO more important is, to turn qbs.io into an attractive landing 
> page. It should become more clear, that Qbs is no longer a The Qt Company 
> project. Might be worth to pay a web designer to come up with a professional 
> looking.  Any volunteers? https://bugreports.qt.io/browse/QBS-1341
> 
> Richard
___
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?

[Иван Комиссаров]

I don't know how does the cmake scripts work, but it should not require 
building qbs with cmake
However, it might be a good idea to retire qmake for qbs as well to reduce Qt 
dependencies. But it seems quite a huge job since qbs build is quite 
complicated and supports lots of configurations.

Иван Комиссаров

> 14 мая 2019 г., в 11:44, Denis Shienkov  написал(а):
> 
> 14.05.2019 12:32, Tobias Hunger пишет:
>> There is no find_package script for qbs that we can just use.
>> 
>> Don't panic, it will be there.
> 
> In that case, you need to add possibility to build the QBS with CMake... No? 
> :)
> 
> Or, how are you going to solve this?
> 
> BR,
> 
> Denis
> 
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

+1

However, will this help to get new developers? Right now, there are not that 
many contributors.

Иван Комиссаров

> 14 мая 2019 г., в 11:18, Карелин Павел  написал(а):
> 
> +1
> 
> 14.05.2019 11:54, Алексей Скородумов пишет:
>> Hi,
>> 
>> Is it hard to make "donate" button on "QBS site" as a part of "transition to 
>> community"?
>> I can't contribute time right now, but would like to support the project.
>> 
>> --
>> Best regards,
>> Aleksei Skorodumov
>> 
>> 
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

Yes, I overlooked that section, there are too many «building» words on this 
page=)
Here’s the review https://codereview.qt-project.org/#/c/260211/ 
<https://codereview.qt-project.org/#/c/260211/>

Meanwhile, I get another question… I think, I already asked it, but still. Is 
the magic behind config parameter documented somewhere?
For example, qbs build config:debug builds a debug build, this is clear from 
the examples…

What other possible options do I have? From what I’ve found, only «release» and 
«debug» are supported, but this is not documented. What do you think about 
adding support for «releaseWithDebugInfo»? This is kinda common usecase.

> 30 апр. 2019 г., в 9:59, Christian Kandeler  
> написал(а):
> 
> On Tue, 30 Apr 2019 08:22:05 +0200
> Иван Комиссаров  wrote:
> 
>> I want to add doc about how to run tests using QBS. But I can’t find 
>> Appendix A page, surprisingly, it is not near Appendix B page.
>> Christian, can you please point to the correct page location?
> 
> You mean in the sources? In the qbs.qdoc file. grep is your friend ;)
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

I want to add doc about how to run tests using QBS. But I can’t find Appendix A 
page, surprisingly, it is not near Appendix B page.
Christian, can you please point to the correct page location?

> 13 февр. 2019 г., в 16:10, Иван Комиссаров  написал(а):
> 
> The same as we discussed earlier - I can't do "try pkg-config module, if 
> fails, try probe-based-detect, if fails, fallback to user-defined paths".
> This is because I can't set the condition of the module based on a probe 
> result and only one module is loaded; if it fails, no fallback occurred.
> 
> Иван Комиссаров
> 
>> 13 февр. 2019 г., в 15:59, Christian Kandeler  
>> написал(а):
>> 
>> On Wed, 13 Feb 2019 15:26:00 +0100
>> Иван Комиссаров  wrote:
>> 
>>> I see that module providers feature was implemented. Is it now possible to 
>>> use a provider to create a module for auto-detected protobuf library (via 
>>> probes and via pkg-config)?
>> 
>> Which problem are you trying to solve?
>> 
>> 
>> Christian
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] qbs 1.13 released

[Иван Комиссаров]

Done: https://bugreports.qt.io/browse/QTCREATORBUG-22355

> 23 апр. 2019 г., в 13:03, Christian Kandeler  
> написал(а):
> 
> On Tue, 23 Apr 2019 13:29:57 +0300
> Иван Комиссаров  wrote:
> 
>> I’ve noticed, that cpp.minimumOsxVersion was renamed to 
>> cpp.minimumMacosVersion at some point of time and QtCreator’s clang code 
>> model does not understand this property. At least, it highlights 
>> std::visit() call which requires cpp.minimumMacosVersion: «10.14» or higher. 
>> Qbs builds project well, so it's clearly some integration bug. However, I 
>> could not find where QBS provides properties to the qtc. Any ideas?
> 
> Please file a bug report for Qt Creator.
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] qbs 1.13 released

[Иван Комиссаров]

Thanks for the job!

I’ve noticed, that cpp.minimumOsxVersion was renamed to cpp.minimumMacosVersion 
at some point of time and QtCreator’s clang code model does not understand this 
property. At least, it highlights std::visit() call which requires 
cpp.minimumMacosVersion: «10.14» or higher. Qbs builds project well, so it's 
clearly some integration bug. However, I could not find where QBS provides 
properties to the qtc. Any ideas?

> 18 апр. 2019 г., в 18:37, Christian Kandeler  
> написал(а):
> 
> https://blog.qt.io/blog/2019/04/18/qbs-1-13-released/
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Unexpected behavior of MSVC generator

[Иван Комиссаров]

Anyway, I still don’t see the problem - QBS can emulate the build process for 
that an IDE normally does, placing the artifacts in the exact places where IDE 
would place them. At least, that’s how (unfinished) Xcode generator works - it 
builds the app to a generic folder and then creates symlinks to the artifacts 
so XCode can find them (symlinks are located in places where Xcode outs 
binaries during «native» build. Why this approach won’t work for bare metal IDE?

> 18 февр. 2019 г., в 20:38, Denis Shienkov  
> написал(а):
> 
> > One can argue the other way round, too: Why would A have to take care of 
> > "native" export to B when B does not care for importing A?
> 
> Because - 'A' is an universal cross-platform tool, aka QBS. And 'B' - it is 
> usually a narrowly specialized vendor-specific tool.
> 
> And a tool 'B' does not known nothing about 'A'.
> 
> But:
> - tool 'B' has a better debugger than a tool 'A' and this debuger are 
> integrated only to the IDE of tool 'B'.
> - tool 'B' has a worse IDE editor than a tool 'A' (e.g. QtC).
> 
> So, we just create a cross-platform project on a tool 'A' (on QBS) and to 
> generate required project for a tool 'B' , 'C' or something else to use this 
> generated project in that tools. It can be useful e.g. for debugging 
> purposes, or when a customer want to have a resulting project sources in a 
> "native" tool.
> 
> Of course, the developer can start developing a project using the required 
> target native tool 'B', 'C' and etc.. but usually, this tools have an ugly 
> IDE with a code editors (which causes a "vomiting reflex").
> 
> PS: I say about the bare-metal programming industry. It just a my thoughts 
> and wants. For me it would be a more comfortable to use the QtC && QBS with 
> generators. :)
> 
> 
> 18.02.2019 22:11, André Pönitz пишет:
>> On Sun, Feb 17, 2019 at 09:10:32PM +0300, Denis Shienkov wrote:
 For c++ - yes. Imagine a pure javascript rule that doesn’t invoke any
>>> «compiler» (like cl or javac) but converts some input to output using qbs
>>> itself. How that custom rule would like?
>>> 
>>> But we speak about c/c++ :)
>>> 
 What are pros?
>>> Pros are than I can use then a generated 'native' project on hosts without
>>> of QBS (just use that 'native' IDE && tools)!  F.e. using a 'native'
>>> debugger and etc.
>> One can argue the other way round, too: Why would A have to take care of
>> "native" export to B when B does not care for importing A?
>> 
>> The soft spot in such cases of interoperability is typically somewhere
>> in between: Both sides should care somewhat of the other.
>> 
>> Andre'
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Unexpected behavior of MSVC generator

[Иван Комиссаров]

> 16 февр. 2019 г., в 19:04, Denis Shienkov  
> написал(а):
> 
> Why is it a very challenging task?
> 
> It is enough just to parse the QBS project, to take a compiler flags, 
> architectures,
> defines and so on, and to create the MSVC project using that info. And then 
> the 
> Visual Studio will invoke all required stuff 'as usual' using own resources.
> 

For c++ - yes. Imagine a pure javascript rule that doesn’t invoke any 
«compiler» (like cl or javac) but converts some input to output using qbs 
itself. How that custom rule would like?

> 
> Yes, of course, generating of the Qt-based project will cause some 
> difficulties
> (due to MOC and etc)... But for non-qt projects it should work. 
> 
> PS: Besides, the Qt MSVC addon and the CMake solves it anyway... Why QBS 
> can't? :)
> 

It can. But when choosing 2 ways of doing same thing, you write down pros and 
cons and compare those ways. The cons are - it’s harder to implement the proper 
generator than the fake one (simply because «proper generator» will include the 
«fake» one for the case I mentioned above). What are pros?
> 
> > What’s the point of implementing a rule for cpp files directly in the 
> > solution and not implementing it for other cases? I don’t see any use cases.
> 
> I'm don't understand a bit, what do you mean here?
> 
What I am trying to tell is that current approach may not be perfect, but it 
works. Unless you can say what’s wrong with it. You need to describe what’s 
wrong and prove that it can’t be fixed due to the chosen approach. For now 
you’re just saying that QBS behaves different from CMake. Well, this is not a 
new information=))

> UPD: I'm ask all this question, because I'm doubt: is it makes sense tries to 
> implement the generators (to spent a time) for a "bare-metal" stuff... e.g. 
> to generate the projects for IAR, Keil, Atmel Studio and etc? Or QBS is dead, 
> and we need to make tries to use CMake for that cases (but I'm don't know and 
> don't like CMake)? It is a main dilemma! :)
> 

It’s open source now. If personally you need this feature, contribute it.

> BR, 
> 
> Denis
> 
> 
> 
> 16.02.2019 20:14, Иван Комиссаров пишет:
>> I can comment. If you want a real generator, you should use cmake=)
>> 
>> Being serious, it is not a recursion, it is a proxy - solution is the proxy 
>> for the IDE to call the build tool (which is QBS).
>> Creating a «proper» solution that invokes compilers directly is a very 
>> challenging task… Imagine you have a custom (not the *.cpp -> *.o) rule for 
>> generating some files with a bunch of JS code. How are you going to invoke 
>> this code? Well, you probably would like to call QBS… But if you’re calling 
>> it for *some* cases why not call it in *all* cases and save some time?
>> 
>> What’s the point of implementing a rule for cpp files directly in the 
>> solution and not implementing it for other cases? I don’t see any use cases.
>> 
>>> 16 февр. 2019 г., в 16:10, Denis Shienkov  
>>> <mailto:denis.shien...@gmail.com> написал(а):
>>> 
>>> Hi all,
>>> 
>>> It was surprised for me, that a generated MSVC solution file has
>>> a build commands which are calls the QBS to build the generated
>>> MSVC solution... It is recursion!!! o_O
>>> 
>>> WTF? But it has not a sense!
>>> 
>>> If I want to build a project using the QBS, then I know that I
>>> will use the QBS!
>>> 
>>> But when I want to generate the MSVC project, then I will expect
>>> that the QBS will generate the 'native' MSVC solution, which I
>>> will use in the Visual Studio IDE on a host without of the QBS!
>>> 
>>> Any comments?
>>> 
>>> BR,
>>> Denis
>>> 
>>> ___
>>> Qbs mailing list
>>> Qbs@qt-project.org <mailto:Qbs@qt-project.org>
>>> https://lists.qt-project.org/listinfo/qbs 
>>> <https://lists.qt-project.org/listinfo/qbs>

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

Re: [Qbs] Unexpected behavior of MSVC generator

[Иван Комиссаров]

I can comment. If you want a real generator, you should use cmake=)

Being serious, it is not a recursion, it is a proxy - solution is the proxy for 
the IDE to call the build tool (which is QBS).
Creating a «proper» solution that invokes compilers directly is a very 
challenging task… Imagine you have a custom (not the *.cpp -> *.o) rule for 
generating some files with a bunch of JS code. How are you going to invoke this 
code? Well, you probably would like to call QBS… But if you’re calling it for 
*some* cases why not call it in *all* cases and save some time?

What’s the point of implementing a rule for cpp files directly in the solution 
and not implementing it for other cases? I don’t see any use cases.

> 16 февр. 2019 г., в 16:10, Denis Shienkov  
> написал(а):
> 
> Hi all,
> 
> It was surprised for me, that a generated MSVC solution file has
> a build commands which are calls the QBS to build the generated
> MSVC solution... It is recursion!!! o_O
> 
> WTF? But it has not a sense!
> 
> If I want to build a project using the QBS, then I know that I
> will use the QBS!
> 
> But when I want to generate the MSVC project, then I will expect
> that the QBS will generate the 'native' MSVC solution, which I
> will use in the Visual Studio IDE on a host without of the QBS!
> 
> Any comments?
> 
> BR,
> Denis
> 
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

The same as we discussed earlier - I can't do "try pkg-config module, if fails, 
try probe-based-detect, if fails, fallback to user-defined paths".
This is because I can't set the condition of the module based on a probe result 
and only one module is loaded; if it fails, no fallback occurred.

Иван Комиссаров

> 13 февр. 2019 г., в 15:59, Christian Kandeler  
> написал(а):
> 
> On Wed, 13 Feb 2019 15:26:00 +0100
> Иван Комиссаров  wrote:
> 
>> I see that module providers feature was implemented. Is it now possible to 
>> use a provider to create a module for auto-detected protobuf library (via 
>> probes and via pkg-config)?
> 
> Which problem are you trying to solve?
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

I see that module providers feature was implemented. Is it now possible to use 
a provider to create a module for auto-detected protobuf library (via probes 
and via pkg-config)?

Иван Комиссаров

> 12 дек. 2018 г., в 10:24, Christian Kandeler  
> написал(а):
> 
> On Tue, 11 Dec 2018 21:27:00 +0100
> Иван Комиссаров  wrote:
> 
>> That helped, thanks!
>> 
>> Now I’ve a got a question about module priority. Perhaps I didn’t get the 
>> idea - I tried to use two "internal.libprotobuf"  modules with different 
>> priority hoping that if failed to configure, the other will be loaded. But 
>> it looks like only one module is loaded, with the highest priority and if it 
>> fails, others are not loaded.
> 
> Yes, the process is less dynamic than you imagined. I suppose it could be 
> implemented, but it wouldn't be trivial at all.
> 
>> Maybe it’s worth trying to load all modules in a chain one after the other?
> 
> That's probably the most sensible approach. Take a look at the first
> example here:
> https://doc.qt.io/qbs/qml-qbslanguageitems-depends.html#details
> 
> 
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

That helped, thanks!

Now I’ve a got a question about module priority. Perhaps I didn’t get the idea 
- I tried to use two "internal.libprotobuf"  modules with different priority 
hoping that if failed to configure, the other will be loaded. But it looks like 
only one module is loaded, with the highest priority and if it fails, others 
are not loaded.

Maybe it’s worth trying to load all modules in a chain one after the other?

> 11 дек. 2018 г., в 10:37, Christian Kandeler  
> написал(а):
> 
> On Mon, 10 Dec 2018 22:50:14 +0100
> Иван Комиссаров  wrote:
> 
>> https://codereview.qt-project.org/#/c/247814/1
>> 
>> Can you please take a look what I am doing wrong? 
> 
> Don't use ids in Depends items, that won't work properly. Always refer to a 
> module by its real name. You then also need to rename the "private" prefix to 
> something else, as that is a reserved word in JavaScript.
> 
> 
> Christian
> ___
> Qbs mailing list
> q...@lists.qt-project.org
> https://lists.qt-project.org/listinfo/qbs

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

[Qbs] Mysterious config: parameter

[Иван Комиссаров]

Perhaps, I am blind, but I can’t find any mentions in documentation.
What’s this is used for? Does this parameter only specifies the output folder 
where QBS will build sources?
Or it has some other usages I am not aware of?
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Future of Qbs

[Иван Комиссаров]

Richard, thank you for writing this post. I was thinking of doing it myself, 
but I never was good at writing long letters=)

Anyway, I would like to suggest that people who interested in QBS start 
contributing in it now. We have half a year to get familiar with the codebase 
while Christian Kandeler is still here.
The main point of doing this is to have a new maintainer for the project after 
the last release by TQtC.
I started investigation in Xcode generator (but help is welcome), I’ll spent a 
bit time on experimenting with clang on Windows.
People willing to contribute, please do so. Back to the original post, we will 
need some coordination. This mailing list?

> 31 окт. 2018 г., в 6:51, Richard Weickelt  написал(а):
> 
> Dear all,
> 
> on the Qt developer mailing list, Lars Knoll recently announced:
> 
>> We have been developing Qbs over the last years, and as such are
>> committed to it for some more time. We are planning on another feature
>> release in the first quarter of next year and will support it in Qt
> 
>> Creator for at least another year. Qbs is open source and if someone
>> wants to take over and develop it further let us know as well. I’d also
>> like to use this place to thank Christian and Jörg for all their great
>> work on Qbs  (and of course also anybody else who contributed to it).
> 
> Qbs is open source but the largest part of development has always been
> shouldered by The Qt Company and the decision processes have never been open
> and transparent.
> 
> It would be great if the TQtC could clarify what is planned for the next
> feature release and why. I would be glad if the TQtC would spend the
> remaining resources on transitioning the Qbs project into a community
> ownership. I have no experience how a successful transition could look like.
> Therefore I am asking for role models.
> 
> What I can think of, but I might be wrong: TQtC maintainers, please
> communicate upfront what you are going to do, how and why so that others can
> learn. Some questions, I think, we should clarify on the mailing list:
> 
> - Can we define milestones for a successful transition and clarify what
>  TQtC is willing to invest?
> - There were some companies using Qbs for their own projects [1]. Can we get
>  committment from those?
> - Can we keep using TQtC infrastructure, domain wtc.?
> - How does the release process of Qbs work?
> - Are there parts in the codebase that make maintenance difficult and
>  that could be simplified? Maybe parts duplicating Qt code that should
>  be rebased onto Vanilla Qt?
> 
> Thank You
> Richard Weickelt
> 
> 
> [1]
> https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs

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

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

Ok, I forgot about objective-C, so yes, I will use explicit property.

Anyway, I got a question, does product.dependencies contains only strict
dependencies (specified at Product item), or the list of all dependencies,
including deps from dependent products/modules?

2018-08-09 12:16 GMT+03:00 Christian Kandeler :

> On Thu, 9 Aug 2018 03:53:50 +0300
> Иван Комиссаров  wrote:
>
> > Im a bit stuck with protobuf module. I’m trying to make the module
> behave different for different languages, i.e. generate .cc files for cpp
> project, java for java project and so on.
> >
> > I am trying to use product.dependencies[i].name == «cpp» condition. It
> works in the outputArtifacts section, but i can’t provide a conditionally
> exported cpp.staticLibraries: ["protobuf»]
>
> I  assume you are referring to the suggestion in the bug report to
> auto-detect the target language? I'm not sure this is so valuable, and we
> could easily guess wrong. What if a project has both a cpp and a Java
> dependency? What about C++ vs Objective-C? Both come from the cpp module...
> I suggest providing a property targetLanguages where the user can set the
> language(s) explicitly and have matching conditions in the respective rules
> (or have just one rule, but different ones might be cleaner).
> Coming up with a good default value seems a bit tricky, but perhaps we can
> just leave it empty and inform the user that it needs to be set.
>
> > Here’s the code https://pastebin.com/gNMiNg7G <
> https://pastebin.com/gNMiNg7G>
> >
> > I tried to tie cpp.staticLibraries to each artifact (but i guess the
> libraries are ignored for cpp tags) and i tried to use a Properties but it
> seems my condition function is not called at all (at least, throwing in it
> makes no result)
>
> It makes no sense to set cpp.*Libraries on an artifact. The linker rule
> reads this property from the product level.
>
>
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

Im a bit stuck with protobuf module. I’m trying to make the module behave 
different for different languages, i.e. generate .cc files for cpp project, 
java for java project and so on.

I am trying to use product.dependencies[i].name == «cpp» condition. It works in 
the outputArtifacts section, but i can’t provide a conditionally exported 
cpp.staticLibraries: ["protobuf»]

Here’s the code https://pastebin.com/gNMiNg7G <https://pastebin.com/gNMiNg7G>

I tried to tie cpp.staticLibraries to each artifact (but i guess the libraries 
are ignored for cpp tags) and i tried to use a Properties but it seems my 
condition function is not called at all (at least, throwing in it makes no 
result)

> 6 авг. 2018 г., в 16:39, Иван Комиссаров  написал(а):
> 
> https://bugreports.qt.io/browse/QBS-563 
> <https://bugreports.qt.io/browse/QBS-563> (Add support for Google Protocol 
> Buffers) It seems that shouldn't be very hard to implement a module for a 
> protoc.

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

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

I don’t think it’s too hackish, but there may be some corner cases that will 
require proper documentation.
What comes to my mind, how you suppose to treat positionalArguments() of the 
top-level parser? Should it be empty/contain all subparser arguments/what’s 
left after subparsing?
Anyway, I used QCommandLineParser for the qbs-style command line parsing and 
that worked except it requires a lot of copy/pasting 

> 7 авг. 2018 г., в 0:58, Richard Weickelt  написал(а):
> 
> 
>>> https://bugreports.qt.io/browse/QBS-511 (QBS help text is not properly
>>> format in windows cmd shell) I guess, QBS doesn't use QCommandLineParser at
>>> the moment?
>> 
>> No, and I don't think it can, because of the "command plus additional 
>> arguments" syntax that qbs uses.
> 
> This would be a very useful add-on in QCommandLineParser. Is the following
> work-around too hackish?
> 1. Parse the second argument in argv (or QCoreApplication::arguments())
> manually in order to deduce the command before initializing an appropriate
> QCommandLineParser object.
> 2. Then remove the second argument and pass the resulting list (without the
> command) to QCommandLineParser.
> 
> 1. qbs build --options
> 2. qbs --option ...
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs

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

Re: [Qbs] cpp.runtimeLibrary:"static" under MSVC2013

[Иван Комиссаров]

Not sure if that helps, but i got same error with _shared_ linkage when
library didn't exported any symbols due to incorrect defines passed to the
linker (Q_DECL_EXPORT/Q_DECL_IMPORT); in that case linker doesn't create an
empty .lib file (is that a QBS bug, btw?). So you can try checking if the
library is statically build or it still tries to build a shared lib somehow.

2018-08-06 16:16 GMT+03:00 Dorian Jicquel :

> Here you go :
>
>
> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN/link.exe
> /nologo /DEBUG /PDB:untitled2.pdb /MACHINE:X86 /APPCONTAINER:NO
> /OSVERSION:5.01 "/SUBSYSTEM:CONSOLE,5.01" /MANIFEST:embed
> C:\Users\djicquel\Documents\build-untitled2-Qt_5_4_1_Mana_
> 32-Debug\qtc_Qt_5_4_1_Mana_32_Debug\untitled2.57dd9e61\3a52ce780950d4d9\main.cpp.obj
> C:\Users\djicquel\Documents\build-untitled2-Qt_5_4_1_Mana_
> 32-Debug\qtc_Qt_5_4_1_Mana_32_Debug\untitled2.57dd9e61\
> 3a52ce780950d4d9\qrc_qml.cpp.obj C:\Qt\qt-5.4.1-mana\msvc2013\lib\Qt5Cored.lib
> C:\Qt\qt-5.4.1-mana\msvc2013\lib\Qt5Guid.lib 
> C:\Qt\qt-5.4.1-mana\msvc2013\lib\Qt5Networkd.lib
> C:\Qt\qt-5.4.1-mana\msvc2013\lib\Qt5Qmld.lib 
> C:\Qt\qt-5.4.1-mana\msvc2013\lib\Qt5Quickd.lib
> Shell32.lib C:\Qt\qt-5.4.1-mana\msvc2013\lib\qtmaind.lib
> /OUT:C:\Users\djicquel\Documents\build-untitled2-Qt_
> 5_4_1_Mana_32-Debug\qtc_Qt_5_4_1_Mana_32_Debug\untitled2.57dd9e61\untitled2.exe
> /LIBPATH:C:\Qt\qt-5.4.1-mana\msvc2013\lib
>
> LINK : fatal error LNK1104: cannot open file 'libcpmtd.lib'
>
>
>
> Dorian.
>
> Le 06/08/2018 à 15:14, Christian Kandeler a écrit :
>
> On Mon, 6 Aug 2018 14:56:48 +0200
> Dorian Jicquel   
> wrote:
>
>
> Since Qbs 1.12 i have some troubles compiling projects with
> cpp.runtimeLibrary:"static" enabled under msvc2013 ( i use build tools ).
>
> Everything works fine with msvc2015 so i don't know if it's related to
> my setup but since it used to work before i'm not sure of it.
>
> Here is the error message : *cannot open file 'libcpmtd.lib'.*
>
> What does the command line that causes the error look like?
>
>
> Christian
> ___
> Qbs mailing 
> listQbs@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/qbs
>
>
>
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Any novice tickets

[Иван Комиссаров]

Hello, Christian. Thank you for the quick answer.

Most of the time i use Mac OS for desktop development, sometimes I use
debian-based Linux.

I looked more at the issues and found some
https://bugreports.qt.io/browse/QBS-563 (Add support for Google Protocol
Buffers) It seems that shouldn't be very hard to implement a module for a
protoc.
https://bugreports.qt.io/browse/QBS-120 (Qbs uses too much memory) I can
take a look at allocations Instrument to see what's happening
https://bugreports.qt.io/browse/QBS-511 (QBS help text is not properly
format in windows cmd shell) I guess, QBS doesn't use QCommandLineParser at
the moment?

2018-08-06 11:28 GMT+03:00 Christian Kandeler :

> On Mon, 6 Aug 2018 11:21:28 +0300
> Иван Комиссаров  wrote:
>
> Hi Ivan,
>
> > Hello, I want to participate in QBS development,
>
> That's great to hear.
>
> > but I don't know where to start. I looked at the open issues at bug
> tracker, but all of them seems rather complicated and requires knowledge of
> the qbs architecture. Are there any easy tickets to start so I can get
> familiar with the codebase?
>
> I'd ignore the qbscore library for now and look for things that can be
> achieved by writing or adapting modules. Which are your preferred platforms?
>
>
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Multiple install paths

[Иван Комиссаров]

Anyone?:(

Иван Комиссаров

> 16 мая 2018 г., в 12:44, Иван Комиссаров <abba...@gmail.com> написал(а):
> 
> Hello, is it posssible to install same product to different folders using one 
> group?
> For example, i have 2 Application Bundles on mac and a plugin that should be 
> installed into both bundles.
> What is the correct way of doing this?
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] Multiple install paths

[Иван Комиссаров]

Hello, is it posssible to install same product to different folders using
one group?
For example, i have 2 Application Bundles on mac and a plugin that should
be installed into both bundles.
What is the correct way of doing this?
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] "bundle.content" and libraries within app bundle

[Иван Комиссаров]

Thanks for the fix. Should i manually rebuild QtC to use the patch?

2017-06-26 20:34 GMT+03:00 Jake Petroules <jake.petrou...@qt.io>:

>
> > On Jun 26, 2017, at 7:10 AM, Christian Kandeler <
> christian.kande...@qt.io> wrote:
> >
> > On Mon, 26 Jun 2017 12:40:40 +0300
> > Иван Комиссаров <abba...@gmail.com> wrote:
> >
> >> I want to install library products into the application bundle, like Qt
> Creator does.
> >>
> >> I modified install-bundle example so the framework is installed into
> >>
> >> Here’s the example https://pastebin.com/dU3gxjQ4 <
> https://pastebin.com/dU3gxjQ4>
> >>
> >> However, i get the following error when i try to launch app from Qt
> Creator:
> >>
> >> Starting /Users/arch/Programming/qt5/build-install-bundle-Desktop_
> Qt_5_7_1_clang_64bit-Debug/qtc_Desktop__1f2d618d-debug/.tmp/Window...
> >> dyld: Library not loaded: CoreUtils.framework/Versions/A/CoreUtils
> >> Referenced from: /Users/arch/Programming/qt5/
> build-install-bundle-Desktop_Qt_5_7_1_clang_64bit-Debug/
> qtc_Desktop__1f2d618d-debug/.tmp/Window
> >> Reason: image not found
> >>
> >> Ok, i didn’t set the cpp.rpath property, however, why does QtC launches
> app from .tmp but not from install-root? Is this a bug?
> >
> > Possibly. It appears your executable does not have qbs.install set for
> > some reason. The logic for choosing the executable to run is in
> > qbs::ProductData::targetExecutable(). Debugging into this function
> might give you more insight into what is going on.
> > You might also want to check whether the same thing happens with the
> original install-bundle example.
>
> Sorry. This is actually a bug by omission which broke somewhere during the
> refactoring of bundle handling in Qbs. Here's the patch which fixes bundled
> application running for macOS, iOS, and tvOS:
> https://codereview.qt-project.org/198542
>
> Hopefully this will be part of the 1.8.1 release.
>
> > Christian
> > ___
> > Qbs mailing list
> > Qbs@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/qbs
>
> --
> Jake Petroules - jake.petrou...@qt.io
> The Qt Company - Silicon Valley
> Qbs build tool evangelist - qbs.io
>
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] "bundle.content" and libraries within app bundle

[Иван Комиссаров]

I want to install library products into the application bundle, like Qt Creator 
does.

I modified install-bundle example so the framework is installed into 

Here’s the example https://pastebin.com/dU3gxjQ4 

However, i get the following error when i try to launch app from Qt Creator:

Starting 
/Users/arch/Programming/qt5/build-install-bundle-Desktop_Qt_5_7_1_clang_64bit-Debug/qtc_Desktop__1f2d618d-debug/.tmp/Window...
dyld: Library not loaded: CoreUtils.framework/Versions/A/CoreUtils
Referenced from: 
/Users/arch/Programming/qt5/build-install-bundle-Desktop_Qt_5_7_1_clang_64bit-Debug/qtc_Desktop__1f2d618d-debug/.tmp/Window
Reason: image not found

Ok, i didn’t set the cpp.rpath property, however, why does QtC launches app 
from .tmp but not from install-root? Is this a bug?___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Install group doesn't work

[Иван Комиссаров]

Ok, i found that this line 
https://github.com/ABBAPOH/qbsfish/blob/master/src/app/app.qbs#L8 prevents 
.icns group from working. Seems like a bug for me.

Иван Комиссаров

9 июля 2015 г., в 17:56, Иван Комиссаров abba...@gmail.com написал(а):

 Hi everybody.
 I have a simple group that installs an icns file:
 
 Application {
 Group {
 name: .icns
 condition: qbs.targetOS.contains(osx)
 files: LiMon.icns
 qbs.install: true
 qbs.installDir: install_data_path
 }
 }
 
 install_data_path contains ./LiMon.app/Contents/Resources 
 
 But this group doesn’t work!
 Being copied to the other project, it works.
 Being copied to the other product in this project, it works.
 Any ideas how to debug why it has no effect?
 Removing build dir doesn’t have an effect.
 Bot QtCreator and console qbs ignore this group.
 
 Иван Комиссаров
 
 
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Install group doesn't work

[Иван Комиссаров]

Yep:( Thanks, this seems my bug

Иван Комиссаров

9 июля 2015 г., в 18:02, Christian Kandeler 
christian.kande...@theqtcompany.com написал(а):

On 07/09/2015 04:56 PM, Иван Комиссаров wrote:
 Hi everybody.
 I have a simple group that installs an icns file:
 
 Application {
 
 Group{
 
 name:.icns
 
 condition:qbs.targetOS.contains(osx)
 
 files:LiMon.icns
 
 qbs.install:true
 
 qbs.installDir:install_data_path
 
 }
 
 }

I assume this is not the complete project. In that case, see 
https://bugreports.qt.io/browse/QBS-830.


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

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

[QBS] Install group doesn't work

[Иван Комиссаров]

Hi everybody.
I have a simple group that installs an icns file:

Application {
Group {
name: .icns
condition: qbs.targetOS.contains(osx)
files: LiMon.icns
qbs.install: true
qbs.installDir: install_data_path
}
}

install_data_path contains ./LiMon.app/Contents/Resources 

But this group doesn’t work!
Being copied to the other project, it works.
Being copied to the other product in this project, it works.
Any ideas how to debug why it has no effect?
Removing build dir doesn’t have an effect.
Bot QtCreator and console qbs ignore this group.

Иван Комиссаров

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

Re: [QBS] qbs 1.4.1 released

[Иван Комиссаров]

What about bundle issues?:)

2015-07-03 13:42 GMT+03:00 Christian Kandeler 
christian.kande...@theqtcompany.com:

 Hi,

 qbs 1.4.1 is out now. As usual, it adds a number of bugfixes and minor
 improvements to 1.4.0. Source packages and a binary Windows package can
 be found at http://download.qt.io/official_releases/qbs/1.4.1/.
 This version of qbs is also bundled in Qt Creator 3.4.2.


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

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

Re: [QBS] Using 'cpp' module from Group item

[Иван Комиссаров]

As documentation says, Properties item works like
if () {} else if () {} else {},
but not like if () {} else if () {} {} statement

Offtopic: anyway, why Group and Properties are separate items?

Иван Комиссаров

 12 янв. 2015 г., в 6:28, Andrey Anpilogov anpi...@gmail.com написал(а):
 
 Yup. Properties is exactly what I've been looking for! Thanks.
 
 Here is some notes about this question.
 I'll leave it here for anyone who will google for same issue:
 cpp.defines: base.concat([
 DEFINE_1,
 DEFINE_2,
 ])
 
 Properties {
 condition: project.cpu.contains(NRF51822)
 
 cpp.defines: base.concat([
 CPU_DEFINE_1,
 CPU_DEFINE_2,
 ])
 }
 
 Resulting cpp.defines includes only CPU_DEFINE_1 and CPU_DEFINE_2.
 
 I had to use product variable and concatenate it with cpp.defines in 
 Properties item.
 I guess it happens because in Product there could be only one cpp.define 
 assignment.
 
 
 2015-01-12 4:27 GMT+08:00 Andrew Knight q...@panimo.net 
 mailto:q...@panimo.net:
 Hi,
 
 
 On 01/11/2015 08:02 PM, Andrey Anpilogov wrote:
 Hi,
 
 Seems like condition doesn't work correct:
 
 Group {
  condition: project.cpu.contains(NRF51822)
  cpp.includePaths: ['dir1', 'dir2']
 }
 
 Qbs doesn't add 'dir1' and 'dir2' folders to compiler.
 Is it valid definition?
 
 It looks like you want a Properties item instead. Groups apply to files 
 within the Product, not the Product as a whole.
 
 
 Regards
 
 
 -AK
 
 
 
 -- 
 -- 
 WBR,
   Andrii Anpilogov
   Phone: +86 186-1660-3720
   Skype: anpilogov.andrey
   mailto:anpi...@gmail.com mailto:anpi...@gmail.com, 
 andrii.anpilo...@mesheven.com mailto:andrii.anpilo...@mesheven.com
 
 ___
 QBS mailing list
 QBS@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qbs
 
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [QBS] Is qbs broken?

[Иван Комиссаров]

That's really odd, reboot fixed crash.

Still, trying to use qbs with qt 5.3 doesn't work with the same error about 
QConditional. It seems, qt.core module doesn't generated correctly?

Иван Комиссаров

16 июня 2014 г., в 17:36, Иван Комиссаров abba...@gmail.com написал(а):

 Are there mac test machines?
 
 That's very odd, on Linux new qbs is fine. However, i don't see any previous 
 builds on my mac system, qbs should be wiped completely. But it really seems 
 i have dll hell.
 
 Иван Комиссаров
 
 11 июня 2014 г., в 17:52, Bornemann Joerg joerg.bornem...@digia.com 
 написал(а):
 
 
 It seems that qbs is completely broken right now.
 
 According to the test machines, no.
 Please try a clean build of qbs and see if this changes anything.
 
 
 Joerg
 ___
 QBS mailing list
 QBS@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qbs
 
 
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[QBS] Is qbs broken?

[Иван Комиссаров]

It seems that qbs is completely broken right now.
First, version that is shipped with Qt Creator can't build Qt5.3 apps on Mac:
  qstring.h:765:26: error: no template named 'QConditional' in namespace 
'QtPrivate'; did you mean 'std::conditional'?
QMake works fine.

Next, qbs built from 1.2 branch hangs with the following error:
QObject: Cannot create children for a parent that is in a different thread.
(Parent is qbs::CommandLineFrontend(0x7fff5fbff9f0), parent's thread is 
QThread(0x102110740), current thread is QThread(0x1021176a0)
QEventLoop: Cannot be used without QApplication

Next, qbs built from master branch crashes:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x00014154 in QGenericAtomicOpsQBasicAtomicOps4 ::loadint () 
at 
/Developer/Qt/5.2.1/clang_64/lib/QtCore.framework/Versions/5/Headers/qgenericatomic.h:142
142 T load() const Q_DECL_NOTHROW { return Ops::load(_q_value); }
(gdb) bt
#0  0x00014154 in QGenericAtomicOpsQBasicAtomicOps4 ::loadint 
() at 
/Developer/Qt/5.2.1/clang_64/lib/QtCore.framework/Versions/5/Headers/qgenericatomic.h:142
#1  0x00014154 in QBasicAtomicIntegerint::load 
(this=0xd000) at qbasicatomic.h:142
#2  0x00014819 in QtPrivate::RefCount::ref 
(this=0xd000) at qrefcount.h:57
#3  0x000147e8 in QString (this=0x7fff5fbff370, other=@0x1025029a8) 
at qstring.h:766
#4  0x0001477d in QString (this=0x7fff5fbff370, other=@0x1025029a8) 
at qstring.h:766
#5  0x00010002f653 in qbs::Settings::baseDirectoy (this=0x1025029a0) at 
settings.h:62
#6  0x000100029f04 in qbs::CommandLineFrontend::start 
(this=0x7fff5fbff9c8) at ../../../../qbs/src/app/qbs/commandlinefrontend.cpp:128
#7  0x000100034232 in qbs::CommandLineFrontend::qt_static_metacall 
(_o=0x7fff5fbff9c8, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x102300ed0) at 
/Users/arch/Programming/qt/alien/qbs-build/src/app/qbs/moc_commandlinefrontend.cpp:105
#8  0x00010057ff4b in QObject::event ()
#9  0x000100556199 in QCoreApplication::notify ()
#10 0x000100556c07 in QCoreApplicationPrivate::sendPostedEvents ()
#11 0x0001005a642e in QEventDispatcherUNIX::processEvents ()
#12 0x00010055364d in QEventLoop::exec ()
#13 0x000100556652 in QCoreApplication::exec ()
#14 0x000100021bea in main (argc=5, argv=0x7fff5fbffac8) at 
../../../../qbs/src/app/qbs/main.cpp:81

I have no idea why this happens...

Иван Комиссаров

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

Re: [QBS] Run all tests

[Иван Комиссаров]

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?

Иван Комиссаров

05 сент. 2013 г., в 7:33, Admin ad...@geo-nadir.ru написал(а):

 Hello. 
 
 I need to run all my tests with a single button. Is it possible?
 I have found command line command properties. It shows all properties. So 
 you can do grep or sed yours. 
 
 My command was:
 qbs properties | sed -ne 's/^targetName: \(tst_.*\)/\1/p' | xargs -i{} sh 
 -c 'qbs run -p {} release -- -xml -o {}.xml'
 
 But after checkout I miss this command. 
 I don't like to support list of all my tests in two places (.qbs  .sh).
 
 Thank you.
 
 Andrew.

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