Re: [Qbs] Heads up: Deprecations in master branch
A big +1 from me.
I already ported my products, took me 3 hours and has to go through review,
wasting more time of my colleagues.
Kind regards,
Björn.
Am 05.08.2024 um 19:12 schrieb Jochen Becher via Qbs:
Qbs is now over 10 years old. We are using it with thousands of qbs
files. Still having breaking changes like this is a nightmare: We have
to go through formal release procedures for more than hundred
components, update binary deployments of these, integrate changes into
hundreds of streams, updating thousand files. Not funny and very
expansive.
IMHO you should think about a solution that is backwards compatible,
e.g. keeping the default behaviour and adding something new for future
code.
And btw why should an include path definition be relative to some
importing product and not the exporting product? Your example is a
perfect example why the old behaviour is readable and make sense (at
least from my point of view as a heavy user of qbs and not a developer
of the tool)
Regards, Jochen
Am Freitag, dem 02.08.2024 um 11:04 +0200 schrieb Christian Kandeler
via Qbs:
Hi,
I'd like to point out two upcoming behavior changes.
==
1. Path properties in Export items
Initially, the "product" variable, when used in an Export item,
referred
to the product the Export item was in, i.e. the exporting product.
This
was dubious, because Export items are supposed to behave like
modules,
where the product variable refers to the product that depends on the
module, i.e. the importing product. Therefore, we introduced the
"exportingProduct" variable and changed the behavior in qbs 1.22.
However, we forgot about path properties. Consider this example,
which
you might encounter in a library product:
Export {
Depends { name: "cpp" }
cpp.includePaths: "."
}
Even after the aforementioned change, such a path was still resolved
relative to the exporting product, which was now inconsistent. We
have
therefore deprecated this construct and will change the behavior such
that the base directory will be the importing product's.
Instead, you can simply refer to the exporting product's source
directory explicitly via "exportingProduct.sourceDirectory".
==
2. The "implicit else" for list properties used in Properties items
A long-standing major annoyance with the Properties item was that its
conditions could not overlap to append different values to lists:
Properties {
condition: qbs.targetOS.contains("unix")
cpp.defines: "OS_UNIX"
}
Properties {
condition: qbs.targetOS.contains("linux")
cpp.defines: "OS_LINUX"
}
This now works as intended and produces ["OS_UNIX", "OS_LINUX"] if
the
target OS is Linux.
However, there is a glitch: If the same property is also set outside
a
Properties item, such a value is considered only if none of the
Properties items match. This is fine for scalar properties, for which
there can only be one value, but makes little sense for list
properties,
where you often have common values that you'd like to append to
conditionally. This was traditionally done via the "outer.concat"
idiom,
which is conceptually incompatible with overlapping conditions, as
the
same values will potentially get added to the list several times.
Therefore, for list properties, bindings outside Properties items
will
no longer act as fallbacks, but will be considered unconditionally.
In
the rare cases where the current behavior is wanted, you can use a
Properties item with an explicitly "undefined" condition:
Properties {
condition: undefined
cpp.defines: "OS_NONE"
}
==
The timeline for both of these behavior changes is as follows:
2.5: Deprecation message (opt-in)
2.6: Deprecation message (opt-out)
2.7: Behavior change
I will write another reminder when we actually implement the behavior
switch.
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] Problems with Xml.DomDocument through a module provider
I've updated to current master and the problem persists. But only if the
condition is false, if it's true (for another target) all is fine.
There's a lot in that import, but nothing that sets the version, only one module
which reads it.
Am 14.07.2024 um 00:15 schrieb Иван Комиссаров:
Did you try to apply the patch?
What’s in MyOwnApplicationImport?
I changed the import to CppApplication and it doesn’t recurse
https://pastebin.com/jKMxpWGe, so I’d say the problem is in
MyOwnApplicationImport.
Ivan
12 июля 2024 г., в 23:06, Björn Schäpers написал(а):
No it did not reference it self.
I hit the same problem again (was fixed after updating) with something
similar to:
Project {
name: "Foo"
StaticLibrary {
name: parent.name + " Details"
version: "1.0.0"
Export { version: exportingProduct.version }
}
MyOwnApplicationImport {
condition: someConditionWhichEvaluatesToFalse
name: parent.name
version: details.version
Depends { name: parent.name + " Details"; id: details }
}
}
And it recursed on the applications version property.
Am 03.07.2024 um 23:56 schrieb Иван Комиссаров:
This (again) seems like an infinite recursion
https://bugreports.qt.io/projects/QBS/issues/QBS-1793 and has nothing to do
with XML.
Do you have a property accessing itself (maybe indirectly) by any chance?
Maybe in a Probe?
You can try applying
https://codereview.qt-project.org/c/qbs/qbs/+/568678 locally to debug the
issue (should print the call stack of the prop that invokes recursion) but
note this change was merged out due to a memory leak.
Ivan.
3 июля 2024 г., в 22:59, Björn Schäpers написал(а):
Hi,
sorry for the delay. I've attacked the stack, it was always evaluating the
same property again.
This is qbs at 20de9f301.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to provide an "export" header
My point is: Before just the exporting product needed to depend on the module
which generated the header by a single depends and setting one property on the
module.
Now the product still depends on the module, sets the property, but also has to
state something in its Export section. More (repetitive) work for the same goal.
Currently qbs keeps on breaking stuff, which can be worked around, but that
leads to more work.
* The removal of the fallback provider: Yeah okay, maybe qbspkgconfig is
superior, but the fallback just worked without providing qbsModuleProviders, I
think that is superior in the usage.
* Now I can't generate files outside the build directory anymore, but what did
we gain?
* And as I understood from the recent commits Export { cpp.includePaths:
["include"] } has to be changed to [exportingProduct.sourceDirectory +
"/include" or similar. I also see no gain for the users, only pain.
Am 13.07.2024 um 15:26 schrieb Иван Комиссаров:
You can add it once to the base item of the products (possibly with some
customisation using a prop). Usually there is already such an item in every
product.
Ivan
13 июля 2024 г., в 14:13, Björn Schäpers написал(а):
Am 13.07.2024 um 02:15 schrieb Иван Комиссаров:
12 июля 2024 г., в 23:24, Björn Schäpers написал(а):
Hi,
I have multiple dynamic libraries in my project tree, and use an export header similar to
your qbs_export.h. Overtime the style of those headers had changed a bit and recently I
replaced them by something generated from qbs. I generated them in the source directory,
so that #include "export.hpp" just worked and even worked for the depending
products.
Now (since 67af0c9517b01c482f425a6761b1cf38c486d3c3) that's not possible
anymore, I understand the reasoning, but now I don't know how to solve the
issue. If I generate the file in the build directory I'd have to add it to the
include path, that's easy from the module. But how to add it to the include
path from products depending on the dynamic library? And even further on
products depending on those? The header did just propagate indefinitely, is
there a way to achieve similar things with properties? In that case I even
would exchange the header with just cpp.defines.
That’s what Export item for
DynamicLibrary {
// library stuff here
Export {
Depends { name: «cpp» }
cpp.includePaths: FileInfo.joinPaths(exportingProduct.buildDirectory,
«path», «to», «headers»)
}
}
I know what Export does, but the point is, I have to add that to all my 50+
products.
Although I've had an error in my thoughts. Of course this will work.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to provide an "export" header
Am 13.07.2024 um 02:15 schrieb Иван Комиссаров:
12 июля 2024 г., в 23:24, Björn Schäpers написал(а):
Hi,
I have multiple dynamic libraries in my project tree, and use an export header similar to
your qbs_export.h. Overtime the style of those headers had changed a bit and recently I
replaced them by something generated from qbs. I generated them in the source directory,
so that #include "export.hpp" just worked and even worked for the depending
products.
Now (since 67af0c9517b01c482f425a6761b1cf38c486d3c3) that's not possible
anymore, I understand the reasoning, but now I don't know how to solve the
issue. If I generate the file in the build directory I'd have to add it to the
include path, that's easy from the module. But how to add it to the include
path from products depending on the dynamic library? And even further on
products depending on those? The header did just propagate indefinitely, is
there a way to achieve similar things with properties? In that case I even
would exchange the header with just cpp.defines.
That’s what Export item for
DynamicLibrary {
// library stuff here
Export {
Depends { name: «cpp» }
cpp.includePaths: FileInfo.joinPaths(exportingProduct.buildDirectory,
«path», «to», «headers»)
}
}
I know what Export does, but the point is, I have to add that to all my 50+
products.
Although I've had an error in my thoughts. Of course this will work.___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] How to provide an "export" header
Hi, I have multiple dynamic libraries in my project tree, and use an export header similar to your qbs_export.h. Overtime the style of those headers had changed a bit and recently I replaced them by something generated from qbs. I generated them in the source directory, so that #include "export.hpp" just worked and even worked for the depending products. Now (since 67af0c9517b01c482f425a6761b1cf38c486d3c3) that's not possible anymore, I understand the reasoning, but now I don't know how to solve the issue. If I generate the file in the build directory I'd have to add it to the include path, that's easy from the module. But how to add it to the include path from products depending on the dynamic library? And even further on products depending on those? The header did just propagate indefinitely, is there a way to achieve similar things with properties? In that case I even would exchange the header with just cpp.defines. I similar problem, but not to propagate stuff, will occur for my translation stuff. I made a rule to update the *.ts files when a cpp is changed, and of course I want to commit the translation files and thus they are in the source directory. How about that? As far as I know there is no official support for lupdate within qbs, right? Kind regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Problems with Xml.DomDocument through a module provider
No it did not reference it self.
I hit the same problem again (was fixed after updating) with something similar
to:
Project {
name: "Foo"
StaticLibrary {
name: parent.name + " Details"
version: "1.0.0"
Export { version: exportingProduct.version }
}
MyOwnApplicationImport {
condition: someConditionWhichEvaluatesToFalse
name: parent.name
version: details.version
Depends { name: parent.name + " Details"; id: details }
}
}
And it recursed on the applications version property.
Am 03.07.2024 um 23:56 schrieb Иван Комиссаров:
This (again) seems like an infinite recursion
https://bugreports.qt.io/projects/QBS/issues/QBS-1793 and has nothing to do
with XML.
Do you have a property accessing itself (maybe indirectly) by any chance?
Maybe in a Probe?
You can try applying
https://codereview.qt-project.org/c/qbs/qbs/+/568678 locally to debug the
issue (should print the call stack of the prop that invokes recursion) but
note this change was merged out due to a memory leak.
Ivan.
3 июля 2024 г., в 22:59, Björn Schäpers написал(а):
Hi,
sorry for the delay. I've attacked the stack, it was always evaluating the
same property again.
This is qbs at 20de9f301.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Problems with Xml.DomDocument through a module provider
Hi, sorry for the delay. I've attacked the stack, it was always evaluating the same property again. This is qbs at 20de9f301. Am 13.06.2024 um 00:44 schrieb Иван Комиссаров: What’s the actual stack? Ivan 12 июня 2024 г., в 23:03, Björn Schäpers написал(а): Hi, okay I debugged into it, it's a stack overflow from something completely different. I wonder why the release variant only crashed with the module provider in place. I did try to replicate the issue with a small example, but the problem did not show. So I can't give you anything. Nevertheless thanks, Björn. Am 12.06.2024 um 10:41 schrieb Иван Комиссаров: Hello. The usual. Build Qbs in debug mode and run in the debugger, possibly with --jobs=1. Or attach to the running Qbs Session in QtC/vscode. Alternatively, if you code is public, provide a link to repo to reproduce and we can take a look. Ivan 12 июня 2024 г., в 00:31, Björn Schäpers написал(а): Hi, I've created a module that reads a xml file and exports some of the content through properties, that works nice. I wanted to extend it, so that there is a (predefined) choice of xml files, and one could depend on multiple of these. So I thought a module provider would be the right choice. I have setup the provider, but qbs crashes on the load() of the xml document, a console.info() before is still printed, afterwards not anymore. I've even changed the provider to just depend on the old module and then it also crashes, while the module itself still works if a product depends on it directly. How can I debug what's happening here? Kind regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs stack.txt.zst Description: Binary data ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Problems with Xml.DomDocument through a module provider
Hi, okay I debugged into it, it's a stack overflow from something completely different. I wonder why the release variant only crashed with the module provider in place. I did try to replicate the issue with a small example, but the problem did not show. So I can't give you anything. Nevertheless thanks, Björn. Am 12.06.2024 um 10:41 schrieb Иван Комиссаров: Hello. The usual. Build Qbs in debug mode and run in the debugger, possibly with --jobs=1. Or attach to the running Qbs Session in QtC/vscode. Alternatively, if you code is public, provide a link to repo to reproduce and we can take a look. Ivan 12 июня 2024 г., в 00:31, Björn Schäpers написал(а): Hi, I've created a module that reads a xml file and exports some of the content through properties, that works nice. I wanted to extend it, so that there is a (predefined) choice of xml files, and one could depend on multiple of these. So I thought a module provider would be the right choice. I have setup the provider, but qbs crashes on the load() of the xml document, a console.info() before is still printed, afterwards not anymore. I've even changed the provider to just depend on the old module and then it also crashes, while the module itself still works if a product depends on it directly. How can I debug what's happening here? 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
[Qbs] Problems with Xml.DomDocument through a module provider
Hi, I've created a module that reads a xml file and exports some of the content through properties, that works nice. I wanted to extend it, so that there is a (predefined) choice of xml files, and one could depend on multiple of these. So I thought a module provider would be the right choice. I have setup the provider, but qbs crashes on the load() of the xml document, a console.info() before is still printed, afterwards not anymore. I've even changed the provider to just depend on the old module and then it also crashes, while the module itself still works if a product depends on it directly. How can I debug what's happening here? Kind regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Setting properties for all products
But I still need all products to use the module. Currently I just have all the options within the module and switch depending on qbs.architecture. Am 29.05.2024 um 18:12 schrieb Иван Комиссаров: 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 ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Setting properties for all products
Hi, I have a project with multiple sub projects and products and want to move it to embedded platforms, and thus I want to set compiler flags like mpcu, which should be the same for all products. I know I can do it through the QtCreator kit or the command line, but I'd like that to be commited so that everyone uses the same flags. I didn't find a solution, other than defining a module (or product) which sets the flags and every product has to depend on. Is there another way? Should there be another way? Because adding it to every product is a bit tedious and error prone. Kind regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Windows 11 & (major|minor)-subsystem-version
Am 10.04.2023 um 23:21 schrieb Иван Комиссаров: 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 Unfortunately I've no access to Windows 7 anymore, so I can't help you. As to the fix, I don't think we need to set the minimum windows version lower, we just don't need to use --major-subsystem-version and --minor-subsystem-version. Everything else is working fine. Note: I couldn't fine any meaning full values for the subsystem version, except for minimum and default: https://learn.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-170 While it may be reasonable to think they match the windows version, there is no statement to that and note that the "Posix" subsystem has a default value of 19.90. Kind regards, Björn.___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Windows 11 & (major|minor)-subsystem-version
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
Re: [Qbs] Failed build the project with QBS 1.22.1
Yes.
Am 02.05.2022 um 18:27 schrieb Карелин Павел:
I am using the construct:
Product {
name: "SharedLib"
property var exportIncludePaths: [
"./",
"./shared",
]
Export {
Depends { name: "cpp" }
cpp.includePaths: product.exportIncludePaths
}
}
I got this recipe here in the mailing list.. Perhaps this is your advice
Christian (I don’t remember exactly now).
What construct should I use now? Like this?
cpp.includePaths [
"./",
"./shared",
];
Export {
Depends { name: "cpp" }
cpp.includePaths: [exportingProduct.cpp.includePaths]
}
--
Pavel
02.05.2022 10:59, Christian Kandeler пишет:
On 4/29/22 17:27, Карелин Павел wrote:
[ ... ]
Now the compiler does not see the header file "shared/list.h" from the
SharedLib dependency.
How to fix the problem?
You are likely using "product" in SharedLib's Export item where
"exportingProduct" should be used.
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] How to use qbspkgconfig?
Hi, my main problem is I have MinGW32 und MinGW64, the pkg-config of the latter is first (or only) in PATH, thus dependencies through pkg-config will get the inlcude paths etc. for the 64 bit variant. Now I have a dependency which checks the bitness in the header and errors out on 32 bit. I thought this could be solved with qbspkgconfig and qbsModuleProviders, but it either can't or I fail to see how. And the documentation is not really helping, I'm afraid. I've tried qbsModuleProviders: ["qbspkgconfig"] which fails to find "botan-2", and Qt. So I went for qbsModuleProviders: ["Qt", "qbspkgconfig"], now it only fails to find "botan-2". Do I have to state where to find the .pc files? And if yes how, and why? Then I could just continue to use pkg-config and set the libDirs path, right? Although that would not be nice, since I don't want to hardcode the path. Kind Regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Branch 1.22 created
Am 15.02.2022 um 17:08 schrieb Christian Kandeler:
On 2/15/22 16:54, Björn Schäpers wrote:
You could mention *explicitly* that the meaning of product within an Export
has changed.
I have a lot of
Export {
...
cpp.cxxLanguageVersion: product.cpp.cxxLanguageVersion
}
And that blew on me. I've found out that I should use exportingProduct, but
maybe ease the use for others.
Note that the deprecation started in 1.18:
https://download.qt.io/official_releases/qbs/1.18.0/changes-1.18.0.md
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Okay, did not notice it back then.
I'm not complaining. Just something I stumbled upon.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Branch 1.22 created
Am 15.02.2022 um 16:40 schrieb Christian Kandeler:
Hi,
we branched off Qbs 1.22 today. Scheduled release date for
version 1.22.0 is end of March (together with Qt Creator 7.0).
We recommend users to try this branch with their projects and report back any
new problems they find.
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.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
You could mention *explicitly* that the meaning of product within an Export has
changed.
I have a lot of
Export {
...
cpp.cxxLanguageVersion: product.cpp.cxxLanguageVersion
}
And that blew on me. I've found out that I should use exportingProduct, but
maybe ease the use for others.
Kind regards,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Exporting Dependencies on generated files
Am 15.11.2021 um 09:18 schrieb Christian Kandeler: On 11/12/21 20:33, Björn Schäpers wrote: This should work if you include "hpp" in the type of the generating product. Adding "hpp" as type does indeed result in the complete compilation of the generating product, before the using product is started. But the files were not recompiled if there were changes, so this only helps in the initial build. There is no difference between initial and subsequent builds in this regard. > What was I needed is also to Export cpp.treatSystemHeadersAsDependencies: true. That's an unrelated property that's not relevant for headers that are artifacts of the project. Christian I export the output directory of protobuf as cpp.systemIncludePaths. If I change something in my .proto and say build for the depending product within QtCreator qbs updates the generated files and only after it starts to compile the dependent files, although there were enough idle cores. Setting the "hpp" type did not have the result, changing the .proto files and hitting build did regenerate the headers, but did not recompile the using files, resulting in linker errors. Kind regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Exporting Dependencies on generated files
Am 04.11.2021 um 12:45 schrieb Christian Kandeler:
On 11/4/21 11:22, Björn Schäpers wrote:
we have a static library which uses Protobuf, thus generates the headers, and
compiles the code directly into it.
Static Library {
...
Export {
Depends { name: "cpp" }
Depends { name: "protobuf.cpp" }
cpp.systemIncludePaths: [product.protobuf.cpp.outputDir]
}
}
And some products which depend on that, but qbs does not order files of the
dependent products which include the generated headers after the generation
of these.
Is there a way to ideally make the files which include to depend on the
header generation, or at least block all actions on the dependent product
wait until the static library is build?
This should work if you include "hpp" in the type of the generating product.
Christian
Adding "hpp" as type does indeed result in the complete compilation of the
generating product, before the using product is started. But the files were not
recompiled if there were changes, so this only helps in the initial build.
What was I needed is also to Export cpp.treatSystemHeadersAsDependencies: true.
Regards,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Exporting Dependencies on generated files
Hi there,
we have a static library which uses Protobuf, thus generates the headers, and
compiles the code directly into it.
Static Library {
...
Export {
Depends { name: "cpp" }
Depends { name: "protobuf.cpp" }
cpp.systemIncludePaths: [product.protobuf.cpp.outputDir]
}
}
And some products which depend on that, but qbs does not order files of the
dependent products which include the generated headers after the generation of
these.
Is there a way to ideally make the files which include to depend on the header
generation, or at least block all actions on the dependent product wait until
the static library is build?
If not, where would I have to look to implement stuff like that?
Kind Regards,
Björn.
___
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
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] Library- and Include-Probe for msys GCC on the example of the protobuf module
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
Re: [Qbs] Environment with AutotestRunner
Am 01.12.2020 um 10:50 schrieb Christian Kandeler: On 12/1/20 8:59 AM, Björn Schäpers wrote: I'm developing on Windows and have a 64 Bit Qt in my path, but because the linker in 64 Bit mode is much slower than its 32 Bit counterpart I often develop in 32 Bit. If I run the programs directly from the Creator everything is fine. If I click build for the AutotestRunner it seems that the environment is not correctly set. While it loads correctly the 32 Bit runtime (which is also not on the non modified path) the Qt path is not added and it only finds the 64 Bit Qt5Core.dll (which fails to load). Who is at fault, qbs, QtCreator, or I (something not correctly configured)? The AutotestRunner does not set up the environment automatically (like "qbs run" does). You need to do that yourself. See tests/tests.qbs in the qbs repository for an example. Christian Sorry for not answering any sooner. :) I have now looked into that, but it just adds the path for Qt. That would help for my initial query, but I have tests which depend on other products, which in turn are not in the PATH by default. I have looked a bit into it. Is there any possibility to run the setupRunEnvironment of the correct module from the AutotestRunner.qbs's rule? Otherwise it would be much easier for me to provide a list of tests and just qbs run them sequentially. Greetings, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Using Parameter
Am 01.12.2020 um 11:04 schrieb Christian Kandeler:
On 12/1/20 8:48 AM, Björn Schäpers wrote:
I've tried to create a product which sets compiler warnings (because
cpp.warningLevel: "all" is not enough), and I want to be able to opt in some
more warnings. I found "Parameter" but I have no idea how to use it.
I don't think this is what parameters are for. You should just declare option1
and option2 as normal properties in the Export item and set them in the product:
Export {
Depends { name: "cpp" }
property bool option1: ...
property bool option2: ...
Depends { name: "All Warnings"; option1: true }
Depends { name: "All Warnings"; id: all_warnings }
all_warnings.option1: true
(As you can see, for syntactical reasons such products should preferably get
names that are valid identifiers.)
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Okay thanks, that way I knew, but thought the Parameter would be better.
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Environment with AutotestRunner
Hi, I'm developing on Windows and have a 64 Bit Qt in my path, but because the linker in 64 Bit mode is much slower than its 32 Bit counterpart I often develop in 32 Bit. If I run the programs directly from the Creator everything is fine. If I click build for the AutotestRunner it seems that the environment is not correctly set. While it loads correctly the 32 Bit runtime (which is also not on the non modified path) the Qt path is not added and it only finds the 64 Bit Qt5Core.dll (which fails to load). Who is at fault, qbs, QtCreator, or I (something not correctly configured)? Regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Using Parameter
Hi,
I've tried to create a product which sets compiler warnings (because
cpp.warningLevel: "all" is not enough), and I want to be able to opt in some
more warnings. I found "Parameter" but I have no idea how to use it.
My product:
Product {
name: "All Warnings"
property stringList option1Warnings
property stringList option2Warnings
property stringList cxxWarnings
property stringList warnings
Properties {
condition: qbs.toolchainType === "gcc"
warnings: [...]
cxxWarnings: warnings.concat([...])
option1Warnings: [...]
option2Warnings: [...]
}
Export {
Depends { name: "cpp" }
Parameter { property bool option1 }
Parameter { property bool option2 }
Properties {
condition: option1 && option2
cpp.cFlags:
product.warnings.concat(option1Warnings).concat(option2Warnings)
cpp.cxxFlags:
product.cxxWarnings.concat(option1Warnings).concat(option2Warnings)
}
Properties {
condition: option1
cpp.cFlags: product.warnings.concat(option1Warnings)
cpp.cxxFlags:
product.cxxWarnings.concat(option1Warnings)
}
Properties {
condition: option2
cpp.cFlags: product.warnings.concat(option2Warnings)
cpp.cxxFlags:
product.cxxWarnings.concat(option2Warnings)
}
cpp.cFlags: product.warnings
cpp.cxxFlags: product.cxxWarnings
}
}
I want to use it as followed:
Depends { name: "All Warnings" }
Depends { name: "All Warnings"; option1: true }
My questions:
1. How to access the paramter?
2. It seems the Flags are not exported in that way, is it incorrect?
King regards,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] AutotestRunner in QtCreator
Am 29.11.2020 um 12:37 schrieb Иван Комиссаров: 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 I've tried selecting some tests to run them, but it tried to compile everything. Which at least in my current situation is bad, because I have compile errors on some products. The Autotest Runner is better for me at least right now, but thanks anyhow. Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] AutotestRunner in QtCreator
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
Re: [Qbs] AutotestRunner in QtCreator
Am 24.11.2020 um 10:17 schrieb Richard Weickelt:
What do you mean, it does not show up? It should show up as a product in the project
view, but it is not built by default. In order to "run" it, you need to
1. have application products with the additional type autotest. Just write
something like:
Application {
type: base.concat(["autotest"])
// ...
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.
-Original Message-
From: "Björn Schäpers"
To: qbs@qt-project.org
Sent: Tue, 24 Nov 2020 9:21
Subject: [Qbs] AutotestRunner in QtCreator
Hi,
I've added a AutotestRunner to my Project, but it does not show up in the
Creator, I think this is because it does not create a binary, right?
I've not looked into the code, but how feasible would it be to give the Creator
a fake executable to run the tests?
Another idea I had, but not yet tested, is adding a dummy executable (just empty
main()) which depends on the Runner, then the tests should run, when I build the
dummy, right?
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
[Qbs] AutotestRunner in QtCreator
Hi, I've added a AutotestRunner to my Project, but it does not show up in the Creator, I think this is because it does not create a binary, right? I've not looked into the code, but how feasible would it be to give the Creator a fake executable to run the tests? Another idea I had, but not yet tested, is adding a dummy executable (just empty main()) which depends on the Runner, then the tests should run, when I build the dummy, right? Regards, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Products with Space in Name
Am 26.06.2020 um 13:42 schrieb Christian Kandeler:
On Fri, 26 Jun 2020 13:14:11 +0200
Björn Schäpers wrote:
DynamicLibrary {
name: "FooBar"
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "FooBar" }
cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""]
Eww... This works? You cannot rely on that, these properties are conceptually
private. Please use exports instead:
Yeah just realized it does not work, before that I only tested with
product.buildDirectory.
DynamicLibrary {
name: "FooBar"
Export { property string theDir: product.buildDirectory }
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "FooBar" }
cpp.defines = ["FOO_PATH=\"" + FooBar.theDir + "\""]
}
Does not work:
DynamicLibrary {
name: "Foo Bar"
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "Foo Bar" }
Depends { name: "Foo Bar"; id: foobar }
cpp.defines = ["FOO_PATH=\"" + foobar.buildDirectory + "\""]
Christian
Thanks,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Products with Space in Name
Hi,
I have a lot of products which have spaces in their name. Until now everything
was fine, but now I want to access the property of one of my dependencies. How
to do that with a space in the name, or should spaces in the name be banned
completely?
Works:
DynamicLibrary {
name: "FooBar"
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "FooBar" }
cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""]
}
Does not work:
DynamicLibrary {
name: "Foo Bar"
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "Foo Bar" }
cpp.defines = ["FOO_PATH=\"" + (What to put here?).buildDirectory + "\""]
}
If you wonder what I'm trying to do: Write a plugin (loader) and test it. For
that I need the path where my plugin is located.
If there is a better way to do that I'm all ears.
Kind regards,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Exporting libraries to link only for MinGW
Am 22.02.2020 um 09:56 schrieb Richard Weickelt:
You don't need a group here in the first place. Just
cpp.dynamicLibraries: {
var libs = [];
if(qbs.toolchain.contains("mingw"))
libs = libs.concat(["pthread", "ole32"] )
return libs;
}
Or to be more explicit: You **must** not use the Group item for this purpose.
The Group item selects file artifacts by name or tag and assigns module
properties to them. Since You don’t select any artifacts, the Group has no
effect. You probably want to use the Properties item (which works in modules as
well. The limitation is that only one Properties item should write the same
module property at a time (mutual exclusive). But that seems to be the case in
your example.
Richard
Thanks!
Properties seems to be exactly what I want.
Here what I have now:
StaticLibrary {
files: ["date/include/date/*.h", "date/src/*.cpp"]
name: "date"
Depends { name: "cpp" }
cpp.cxxLanguageVersion: "c++17"
cpp.defines: ["HAS_REMOTE_API=0","AUTO_DOWNLOAD=0","INSTALL=."]
cpp.includePaths: ["date/include"]
Export {
Depends { name: "cpp" }
cpp.defines: product.cpp.defines
cpp.includePaths: ["date/include"]
Properties {
condition: qbs.toolchain.contains("mingw")
cpp.dynamicLibraries: ["pthread", "ole32"]
}
}
}
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Exporting libraries to link only for MinGW
Hi,
I'm trying to incorporate Howard Hinnant's date library and he states
"mingw users: -lpthread and -lole32 are required"
So I tried
StaticLibrary {
files: ["date/include/date/*.h", "date/src/*.cpp"]
name: "date"
Depends { name: "cpp" }
cpp.cxxLanguageVersion: "c++17"
cpp.defines: ["HAS_REMOTE_API=0","AUTO_DOWNLOAD=0","INSTALL=."]
cpp.includePaths: ["date/include"]
Export {
Depends { name: "cpp" }
cpp.defines: product.cpp.defines
cpp.includePaths: ["date/include"]
Group {
condition: qbs.toolchain.contains("mingw")
cpp.dynamicLibraries: ["pthread", "ole32"]
}
}
}
But that doesn't work, even though QtCreator shows the Group as active. It
doesn't matter to what I change the condition, only when I remove the Group at
all the Libraries are added to the link command.
How do I correctly state these dependencies?
Best regards,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Including project files matching git submodules
Am 03.01.2019 um 22:36 schrieb Silvano Cerza:
I think it should be enough to delete up.qbs and remove references:
["../up.qbs"] from lib2.qbs.
Obviously if you export cpp.includePaths you must export a dependency to cpp.
Il giorno gio 3 gen 2019 alle ore 22:17 Björn Schäpers <mailto:qt-maill...@hazardy.de>> ha scritto:
Hi,
I'm trying to build a repository for multiple libraries and applications,
where
every product is located in an own submodule. Right now I'm at this point:
root/
- all.qbs
- libs/
- libs.qbs
- up.qbs
- lib1/
- lib1.qbs
- lib2/
- lib2.qbs
Lib2 needs lib1. The file contents are as follows (striped to what I think
is
relevant):
lib1.qbs
Product {
name: "Lib1"
Export { cpp.includePaths: ["./include"] }
}
lib2.qbs
Project {
references: ["../up.qbs"]
Depends { name: "Lib1" }
}
up.qbs
Project { references: ["../all.qbs"] }
all.qbs
Project { references: ["libs/libs.qbs"] }
libs.qbs
Project { references: ["lib1/lib1.qbs", "lib2/lib2.qbs"] }
Trying to compile lib2 I get the message "Cycle detected while referencing
file
'lib2/lib2.qbs'." And the Include-Path is not added (although QtCreator
did find
the headers for auto completion).
The message is clear, but not how do I solve this problem? I want the
libraries
to be able to use other libraries, without knowing their path, only their
name.
I'm willing to use something like my up.qbs here or maybe a function to
filter
out the current root qbs (in my case lib2.qbs) from the references list,
but I
don't know if this is possible and if how to do it. I have right now no
experience in QML/JS.
Can anybody help me, or show another solution to my problem?
Many thanks in advance,
Björn.
Yeah thanks, of course I had exported the cpp dependency, I just had used the
library qbs files directly and not the root qbs. Now that I'm using the root qbs
I don't need the up.qbs, right.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Including project files matching git submodules
Am 04.01.2019 um 10:21 schrieb Christian Kandeler:
On Thu, 3 Jan 2019 22:14:09 +0100
Björn Schäpers wrote:
I'm trying to build a repository for multiple libraries and applications, where
every product is located in an own submodule. Right now I'm at this point:
root/
- all.qbs
- libs/
- libs.qbs
- up.qbs
- lib1/
- lib1.qbs
- lib2/
- lib2.qbs
Lib2 needs lib1. The file contents are as follows (striped to what I think is
relevant):
lib1.qbs
Product {
name: "Lib1"
Export { cpp.includePaths: ["./include"] }
}
lib2.qbs
Project {
references: ["../up.qbs"]
Depends { name: "Lib1" }
}
up.qbs
Project { references: ["../all.qbs"] }
all.qbs
Project { references: ["libs/libs.qbs"] }
libs.qbs
Project { references: ["lib1/lib1.qbs", "lib2/lib2.qbs"] }
Trying to compile lib2 I get the message "Cycle detected while referencing file
'lib2/lib2.qbs'." And the Include-Path is not added (although QtCreator did find
the headers for auto completion).
The message is clear, but not how do I solve this problem? I want the libraries
to be able to use other libraries, without knowing their path, only their name.
Are you saying you want to be able to open a library project file in isolation
(as opposed to the top-level project) and expect it to know everything else? If
so, may I ask why? Obviously, you are relying on the entire project to be
present anyway, so why not work with that one?
Christian
Yeah on my way to work today I thought I should open the root qbs.
So yes and no, I don't want to be able, until now I just hadn't thought about
using it otherwise.
But I have one more question: Is Project { references: [...] } the only way to
include other files, apart from defining new modules?
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Including project files matching git submodules
Hi,
I'm trying to build a repository for multiple libraries and applications, where
every product is located in an own submodule. Right now I'm at this point:
root/
- all.qbs
- libs/
- libs.qbs
- up.qbs
- lib1/
- lib1.qbs
- lib2/
- lib2.qbs
Lib2 needs lib1. The file contents are as follows (striped to what I think is
relevant):
lib1.qbs
Product {
name: "Lib1"
Export { cpp.includePaths: ["./include"] }
}
lib2.qbs
Project {
references: ["../up.qbs"]
Depends { name: "Lib1" }
}
up.qbs
Project { references: ["../all.qbs"] }
all.qbs
Project { references: ["libs/libs.qbs"] }
libs.qbs
Project { references: ["lib1/lib1.qbs", "lib2/lib2.qbs"] }
Trying to compile lib2 I get the message "Cycle detected while referencing file
'lib2/lib2.qbs'." And the Include-Path is not added (although QtCreator did find
the headers for auto completion).
The message is clear, but not how do I solve this problem? I want the libraries
to be able to use other libraries, without knowing their path, only their name.
I'm willing to use something like my up.qbs here or maybe a function to filter
out the current root qbs (in my case lib2.qbs) from the references list, but I
don't know if this is possible and if how to do it. I have right now no
experience in QML/JS.
Can anybody help me, or show another solution to my problem?
Many thanks in advance,
Björn.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Using self compiled Qbs with self compiled QtCreator
Hi, I try to use self compiled Qbs and QtCreator on Windows (MinGW not MSVC, no msys or cygwin). I'm using a separate Qbs checkout, not the one delivered with QtCreator. My first problem was while compiling QtCreator the linker looked for libqbscore.a, but the file is named libqbscore1.a. Trying to remove the 1 with CONFIG+=skip_target_version_ext for Qbs failed to compile and link Qbs, because it still looks for the 1 version. So I added a copy step to my build routine and everything linked fine. QtCreator seems to find Qbs and I can create a project, and add files. But trying to compile the project ends with: :-1: Fehler: Failed to start process launcher at 'E:\corporate.git\QtCreator\bin\qbs_processlauncher': Das Starten des Prozesses ist fehlgeschlagen: Das System kann die angegebene Datei nicht finden. Which is not surprising, because: E:\>where qbs_processlauncher E:\corporate.git\qbs\bin\qbs_processlauncher.exe Did I do something wrong here? I did not find any configuration possibilities for Qbs inside of QtCreator, especially the path. My directory structure is: - qbs.git - qbs-build - qbs - qt-creator.git - QtCreator I run inside qbs-build: qmake ..\qbs.git\qbs.pro CONFIG-="debug_and_release" CONFIG+="release qbs_enable_project_file_updates" And mingw32-make install INSTALL_ROOT=\path\to\qbs (Afterwards I copy libqbscore1.a and libqbsqtprofilesetup1.a to their counterparts without version number.) For the Creator I run inside QtCreator: qmake ..\qt-creator.git CONFIG-="debug_and_release" CONFIG+="release" LLVM_INSTALL_DIR=\path\to\llvm QBS_INSTALL_DIR=\path\to\qbs QTC_ENABLE_CLANG_LIBTOOLING=true And just plain mingw32-make Of course I can (and will) just copy the qbs_processlauncher.exe into QtCreators bin directory, but this is just a hack. Greetings, Björn. ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
