Re: [Qbs] Long live QBS plugin for VSCode
On Fri, 23 Oct 2020 at 03:41, Denis Shienkov wrote: > > Hi developers, > > Recently, I have started the plugin for the VS Code that support the QBS: > > * https://github.com/denis-shienkov/vscode-qbs Nice! I now have no excuse to not use VSCode now :) Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Evaluation of Conditional Depends
On Sun, 7 Jun 2020 at 04:30, Christian Gudrian wrote: > > Hello! > > In ModuleA there is a property enableFeature which by default is false. > > ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true. > > A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to > true. However, ModuleC is not used as a dependency. That looks like a weird scenario, maybe this means that the enableFeature property is not in the right place. Can't you move it to the top project, and pull it in Module A & B? Or maybe proxy the property in module B, e.g. your product assigns the same value to ModuleA.enableFeature and ModuleB.enableSameFeature? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain
On Sat, 23 May 2020 at 07:34, Richard Weickelt wrote: > > Thus I don't think that it should be made into the official Qbs codebase. > > Maybe this code could be used in some How-To section or something. > > What's your experience in using Qbs with Yocto? Once you solved the > EnvironmentScriptProbe, were there a lot of additional steps needed? Any > pitfalls? I guess a howto would be nice in general and might be interesting > for some people. On the other hand - and without having much knowledge about > yocto - how high is the risk that this howto would be outdated by tomorrow? Yocto is a "classic" for embedded Linux system. It's been around for many years (ages). It is a REFERENCE in this domain, is sponsored by the Linux foundation, and SoC manufacturers contribute mainstream by providing their own "hardware layer". It support all common (and uncommon) architectures used in the industry (PowerPC, Mips, Arm, ...) Last but not least, Yocto is the technology behind Boot2Qt, Qt5 has it's own layer: https://www.yoctoproject.org/software-overview/layers/?searchTerm=meta-qt5, and boot2qt-opensource too: https://code.qt.io/cgit/yocto/meta-boot2qt.git/ Adding support for Yocto to Qbs is IMHO a big win. Unfortunately using Yocto (aka. Poky, OpenEmbedded, ...) starts with sourcing an env file. An alternative to this probe would be a to make the qbs-setup-* tools do the right thing when run from a shell which has sourced that file. That will allow to setup different profiles for different version of Yocto (typ. stable vs dev) and name them accordingly. Call me crazy, but i would say that a qbs-setup-yocto tool that takes a path to an env file would be a good idea, or something similar to qbs-setup-android. FYI, this is the sort of things the env file defines: https://www.yoctoproject.org/docs/2.3.3/sdk-manual/sdk-manual.html#sdk-running-the-extensible-sdk-environment-setup-script IMHO, it is worth having a quick look at the "app developer workflow": https://www.yoctoproject.org/docs/2.3.3/sdk-manual/sdk-manual.html#sdk-use-devtool-to-add-an-application Haven't tried, but i'm suspecting QtC integrates this somehow. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] AAR dependency for APK generation
On Fri, 22 May 2020 at 03:26, Raphael Cotty wrote: > Hi, > qbs runs androiddeployqt with "--aux-mode" argument which disables the use of > gradle. > In this mode androiddeployqt only gathers dependencies. > The rest of the job being made by qbs. > So when you use androiddeployqt directly I guess it's without "--aux-mode". > I could not find much information about what needs to be done to "merge" the > AAR package with the apk. > If anyone has some detailed info we can see how difficult that could be to > add the feature in qbs. > Raph Hi Raph, Here are generic info about AAR, not very useful IMHO. https://developer.android.com/studio/projects/android-library androiddeployqt is a single cpp file (!): https://github.com/qt/qtbase/blob/dev/src/tools/androiddeployqt/main.cpp Couldn't find anything related to aar, i think the magic happens in gradle We currently generate APK via androiddeployqt with CMake. Nothing fancy, we generate androiddeploqt.json an have an android manifest file. That's all: no gradle, no '.properties' file. From our log files, it seems that adq copies recursively the android-package-source-directory, in our case, this means 2 files: AndroidManifest.xml and libs/neon-platform-sdk-0.1.25.aar Going throug adq and gradle logs, I can see: [2020-05-21T12:04:57.166Z] Loading library manifest /home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/AndroidManifest.xml [2020-05-21T12:04:57.166Z] Merging main manifest /home/jenkins/workspace/NEON_Jenkins_neon-testapp_master/builds/armv7-android/sources/TestApp/AndroidManifest.xml [2020-05-21T12:04:57.166Z] [2020-05-21T12:04:57.166Z] Merging library manifest /home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/AndroidManifest.xml [2020-05-21T12:04:57.166Z] Merging manifest with lower [neon-platform-sdk-0.1.25.aar] AndroidManifest.xml:2:1-4:12 [2020-05-21T12:04:57.166Z] Merging result: SUCCESS The manifest in AAR is just http://schemas.android.com/apk/res/android"; package="neon.library"> later on, beside libs/Qt*.jar processing: [2020-05-21T12:04:57.168Z] Jar input /home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar [2020-05-21T12:04:57.168Z] Dexing /home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar ... [2020-05-21T12:04:57.168Z] Dexing '/home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar' to 'file:/home/jenkins/workspace/NEON_Jenkins_neon-testapp_master/builds/armv7-android/sources/TestApp/build/intermediates/transforms/dexBuilder/release/12.jar' [2020-05-21T12:04:57.168Z] Dexing '/home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar' to 'file:/home/jenkins/workspace/NEON_Jenkins_neon-testapp_master/builds/armv7-android/sources/TestApp/build/intermediates/transforms/dexBuilder/release/13.jar' [2020-05-21T12:04:57.169Z] Dexing '/home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar' to 'file:/home/jenkins/workspace/NEON_Jenkins_neon-testapp_master/builds/armv7-android/sources/TestApp/build/intermediates/transforms/dexBuilder/release/14.jar' [2020-05-21T12:04:57.169Z] Dexing '/home/gradle/caches/transforms-1/files-1.1/neon-platform-sdk-0.1.25.aar/37691ba971bd8203bd9bfea5ceeaf89b/jars/classes.jar' to 'file:/home/jenkins/workspace/NEON_Jenkins_neon-testapp_master/builds/armv7-android/sources/TestApp/build/intermediates/transforms/dexBuilder/release/15.jar' I don't know why this is done 4 times again. The AAR is a zip file: res/ values/ colors.xml strings.xml AndroidManifest.xml R.txt classes.jar The above log bits are the only references to AAR i could find. So it seems that this AAR should be unzipped and somehow merged with project's res, assets, manifest, .. and processed like a "java.jar" input. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] AAR dependency for APK generation
Hi there, We have dependencies on a AAR package (a lib if i understand correctly). When building APK with androiddeployqt it magically picks up AAR placed in a android/libs sub-directory. It doesn't seems that qbs support that, has anyone ever used AAR before? Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] isystem with clang
On Wed, 20 May 2020 at 22:39, Christian Gagneraud wrote:
> I understand the cons arguments, and i agree with that, this should be
> under user's control.
>
> A variation could be:
>
> property bool useSystemInclude = name === "Qt.core" ? false :
> Qt.core.useSystemInclude
> Properties {
>condition: useSystemInclude
>cpp.systemIncludePath: ...
> }
> Properties {
>condition: !useSystemInclude
>cpp.includePath: ...
> }
>
> Could it be as simple as that?
I've tried that on Qt.core (w/o name === "Qt.core"), and it works just fine.
Looks like another PR is awaiting me! :)
If people are willing to accept that.
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] isystem with clang
On Wed, 20 May 2020 at 22:24, Christian Kandeler
wrote:
>
> On Wed, 20 May 2020 22:11:20 +1200
> Christian Gagneraud wrote:
>
> > Couldn't find any definite answer about using '-isystem' to avoid the
> > compiler to report warning as error in 3rd party headers (qt, gtest,
> > ...).
> > Looking at the cpp module, i can see some logic, but I can't seem to
> > find a way to force the use of isystem.
> > The only suggestion I found was to hack Qt's modules to change
> > cpp.includePath to cpp.systemIncludePath.
> >
> > Is this still the case, or am i missing something?
>
> Not sure what you mean. Use cpp.systemIncludePaths for things under
> your control. For Qt, the respective patch was rejected for some strange
> reason; see https://codereview.qt-project.org/c/qbs/qbs/+/90492.
I understand the cons arguments, and i agree with that, this should be
under user's control.
A variation could be:
property bool useSystemInclude = name === "Qt.core" ? false :
Qt.core.useSystemInclude
Properties {
condition: useSystemInclude
cpp.systemIncludePath: ...
}
Properties {
condition: !useSystemInclude
cpp.includePath: ...
}
Could it be as simple as that?
This doesn't scale tho, you would need to tweak each 3rd party modules.
Would be nice to take the decision in the Depends item for example:
Somethings that takes the dependency cpp.includePath and transform it
so that it acts as a cpp.systemIncludePath.
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.
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] isystem with clang
Hi there, Couldn't find any definite answer about using '-isystem' to avoid the compiler to report warning as error in 3rd party headers (qt, gtest, ...). Looking at the cpp module, i can see some logic, but I can't seem to find a way to force the use of isystem. The only suggestion I found was to hack Qt's modules to change cpp.includePath to cpp.systemIncludePath. Is this still the case, or am i missing something? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Set cpp properties for generated cpp files (moc) does not seem to work
On Fri, 15 May 2020 at 03:12, Christian Kandeler wrote: > > On Thu, 14 May 2020 14:49:25 + > Maximilian Hrabowski wrote: > > > Isn’t unmocable used to tag cpp/header files that should not be processed > > by moc? > > Sure, that's why the generated cpp files get it, so they won't get processed > again. Is there a similar tag for precompiled qml? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] setup-android, no --system?
On Sat, 16 May 2020 at 02:54, Christian Gagneraud wrote: > > On Sat, 16 May 2020 at 01:46, Richard Weickelt wrote: > > > I was just surprised that --system is supported by all qbs > > > setup/config tools but qbs-setup-android. I don't see any compelling > > > reason for that, do you? > > > Maybe it was simply never needed, hence never implemented. > > > > Probably. It's a valid suggestion though. Wanna submit a patch? > > I'll add that to my TODO list https://codereview.qt-project.org/c/qbs/qbs/+/300683 ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] setup-android, no --system?
On Sat, 16 May 2020 at 01:46, Richard Weickelt wrote: > > I was just surprised that --system is supported by all qbs > > setup/config tools but qbs-setup-android. I don't see any compelling > > reason for that, do you? > > Maybe it was simply never needed, hence never implemented. > > Probably. It's a valid suggestion though. Wanna submit a patch? I'll add that to my TODO list > > As a side note, i don't install Android the same way. I use what i > > believe is the new approach: install commandline-tools first, and run > > sdk manager with a package requirement file, here is mine right now: > > build-tools;28.0.3 > > ndk;21.0.6113669 > > patcher;v4 > > platform-tools > > platforms;android-28 > > Ah thanks. That looks helpful. We should do the same. It would be nice if > you could post a more comprehensive code snippet once you are done. ENV ANDROID_PREFIX /opt/android ENV ANDROID_TOOLS commandlinetools-linux-6200805_latest.zip ENV PATH $ANDROID_PREFIX/cmdline-tools/tools/bin:$PATH ADD $ANDROID_TOOLS android-packages /tmp/ RUN mkdir -p $ANDROID_PREFIX/cmdline-tools \ && unzip -d $ANDROID_PREFIX/cmdline-tools/ /tmp/$ANDROID_TOOLS \ && echo 'y' | sdkmanager --install \ $(cat /tmp/android-packages | grep -v -e '^#' -e '^$') I have comments in my package file, not sure if it's supported or not. If you don't, then you can use: echo 'y' | sdkmanager --install /path/to/requirements/file Similarly, i do: RUN /tmp/install-qt.sh \ --version $QT_VERSION \ --directory $QT_PREFIX \ --target $QT_TARGET \ --toolchain $QT_TOOLCHAIN \ $(cat /tmp/qt-packages | grep -v -e '^#' -e '^$') Thank you so much for that script! Mandatory nitpicks: - use of http, not https - no integrity checks (sha1, but that's what piss me off, see below) - can't install cmake/ninja/conan... (you wouldn't like my patch: "The repository structure is a mess. Try different URL variants") I never understood why they don't have a master checksum file. Downloading gazillion of tiny sha1 files kills the MaintenaceTool friendliness when you're in New Zealand downloading from Japan. Your script makes the process blazing fast (but unsafe). Thanks for that <= odd statement Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] setup-android, no --system?
On Sat, 16 May 2020 at 01:23, Christian Gagneraud wrote: > As a side note, i don't install Android the same way. I use what i > believe is the new approach: install commandline-tools first, and run > sdk manager with a package requirement file, here is mine right now: > build-tools;28.0.3 > ndk;21.0.6113669 > patcher;v4 > platform-tools > platforms;android-28 Not 100% sure if i'm on the right track, but currently my product sets: Android.sdk.platform: "android-28" Android.sdk.buildToolsVersion: "28.0.3" Android.ndk.platform: "android-21" // not sure that's right Because these are the official build requirements (we own the AOSP) I think this is wrong, the project/product shouldn't dictate that, b/c the build env provides it. Similarly, with my upcoming keystore patch, the product sets: Android.sdk.keyStorePath: project.sourceDirectory + "/build-tools/navico-release.jks" Android.sdk.keyStorePassword: "xxx" Android.sdk.keyAlias: "xxx" Android.sdk.keyPassword: "xxx" I don't like this either, so either the container comes with "magic" signing power, or the android package git repo is setup with a proper submodule keystore provider, we have a keystore.properties file that fully define the hosted keystore, so this is a possible solution: Android.sdk.keystoreProperties: "path/to/keystore/properties/file" With both of the above solved transparently, the product just need to define: Android.sdk.packageName Android.sdk.versionName Android.sdk.versionCode Android.sdk.apkBaseName Android.sdk.manifestFile Which sounds just about right to me. Ultimately, signing, ABI, SDK, NDK, selection is driven by the container name/version that is pulled in the project's CI pipeline, which is something the developer controls. Chris We use Jenkins, you use Travis, i prefer Gitlab... ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] setup-android, no --system?
On Sat, 16 May 2020 at 00:49, Richard Weickelt wrote: > > Because this file will end up in some "home" directory, which might > > not be accessible to the end user (eg. custom UID, GID, home, ...) > > Having a system wide qbs conf is bullet-proof in that regard. > > So, yes i would prefer to run the above command, but with '--system' > > and no, you cannot simply move the generated user's conf into > > /etc/xdg/qbs, they don't use the same 'ini' namespace > > Until we are able to run the Docker daemon as non-root user, I am using this > approach: > > 1. set up a user XXX and use whatever uid/gid you like (e.g. 1000). > > https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/test-android.Dockerfile > > 2. enable password-less sudo for this user > 3. switch to that user before running qbs config to set up the profiles > 4. Running the container, mount the current folder as the working dir > 3. add an entrypoint script that looks at the uid/gid of the >working dir and adjust the uid/gid of XXX in the container >to match it. >https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/entrypoint.sh > > 5. Run the container with docker-compose which cuts the Docker command line > down to: > docker-compose run --rm IMAGESERVICENAME qbs build ... > >https://code.qt.io/cgit/qbs/qbs.git/tree/docker-compose.yml >Docker-compose mounts the current directory and does additional stuff >for you. I always have a docker-compose.yml in projects where >the build environment is in a Docker container. > > You can see it in action here: > https://code.qt.io/cgit/qbs/qbs.git/tree/.travis.yml#n75 Hi Richard, Thanks for the detailed explanation, i've been looking at your scripts and docker files recently (and have adopted your install-qt.sh! ;)) I think we don't have the same use case, you need to build and test qbs, i need to build and test a android+qt+qbs container that works "out of the box" whichever way it is used (CI or developers). Basically my ultimate test is: build and sign an hello world APK with this android+qt+qbs container, that depends on all the Qt modules i want to be available to developers. My goal is: just run "qbs build" in the right container and you'll get a signed APK. I was just surprised that --system is supported by all qbs setup/config tools but qbs-setup-android. I don't see any compelling reason for that, do you? Maybe it was simply never needed, hence never implemented. As a side note, i don't install Android the same way. I use what i believe is the new approach: install commandline-tools first, and run sdk manager with a package requirement file, here is mine right now: build-tools;28.0.3 ndk;21.0.6113669 patcher;v4 platform-tools platforms;android-28 Chris Digression: I wish Qbs was in the list of tools i can install with install-qt.sh ... ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] setup-android, no --system?
On Sat, 16 May 2020 at 00:24, Richard Weickelt wrote:
>
> > I find this quite useful when creating docker container.
> > The idea is that the container (name) completely define the whole
> > build config, and running "qbs build" in there build an APK with the
> > "right" configuration.
> > No env involved, no foreknowledge of the profile name, it just work
> > out of the box.
> >
> > My current solution is to add an hand crafted /etc/xdg/qbs/qbs.conf,
> > but i would prefer to generate it with qbs-setup-android and
> > qbs-config from the Dockerfile.
>
> A hand-crafted qbs.conf sounds like overkill. Why can't you just run
> something like
>
> qbs setup-android --ndk-dir ${ANDROID_HOME}/ndk-bundle --sdk-dir
> ${ANDROID_HOME} --qt-dir ${QT_INSTALL_DIR} qbs_autotests-android-qt
>
> qbs config defaultProfile qbs_autotests-android-qt
>
> in the Dockerfile? You need to install all the Android stuff and Qt anyway,
> so you must have that information already.
Because this file will end up in some "home" directory, which might
not be accessible to the end user (eg. custom UID, GID, home, ...)
Having a system wide qbs conf is bullet-proof in that regard.
So, yes i would prefer to run the above command, but with '--system'
and no, you cannot simply move the generated user's conf into
/etc/xdg/qbs, they don't use the same 'ini' namespace
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] setup-android, no --system?
Hi there, Is there some special reason why qbs-setup-android doesn't support the --system option? I find this quite useful when creating docker container. The idea is that the container (name) completely define the whole build config, and running "qbs build" in there build an APK with the "right" configuration. No env involved, no foreknowledge of the profile name, it just work out of the box. My current solution is to add an hand crafted /etc/xdg/qbs/qbs.conf, but i would prefer to generate it with qbs-setup-android and qbs-config from the Dockerfile. Any thoughts? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain
On Fri, 15 May 2020 at 19:46, Kai Dohmen via Qbs wrote: > > Hello, > > I just stumbled across a scenario in which we use with multiple profiles for > different cross compiling toolchains. Yocto creates a script which exports > environment variables. We normally just extract the needed values from the > script and set them as additional qbs profile settings. > This leads to the problem that the ConanfileProbe just calls "conan > install... -p..." without the needed environment variables. Thus when install > libraries they are getting compiled with the wrong toolchain/settings. > What is the proper way of doing this? How do I set the environment variables? > Should I set the variables in the Kit? Personal opinion: I hate yocto simply because it requires to run any of your tool (IDE, build system) under a controlled environment. Things might have changed a bit, eg Boot2Qt is based on yocto, and you can use QtC with boo2qt w/o sourcing an env first. Unfortunately i do not know the details on how they achieved that. IMHO, using Qbs in a way that makes it heavily shell environment dependent is going against Qbs spirit. The profile system is one of Qbs cornerstone. So maybe you could source this env file only once, just before setting up your profiles, and capture all the relevant bits in your profile this way. Just some ideas, i don't know how practical this would be. I haven't use Yocto in ages, could you copy/paste your env file? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Android multiarch
On Fri, 15 May 2020 at 01:01, Raphael Cotty wrote: > > Hi, > Yes, I use qtc to load my multi-arch app. Maybe it's my Android env then. I'm using SDK 26.1, Ndk 21.2 and Platform 28 Build tools are pinned to 28.0.3, not sure if it's a strict requirement for me. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qtc: Cannot find the androiddeploy Json file
On Fri, 15 May 2020 at 00:45, Christian Gagneraud wrote: > > On Fri, 15 May 2020 at 00:16, Raphael Cotty wrote: > > > > Hi, > > The json file used in android_support.qbs is an input file used by the > > androiddeployqt tool to generate the apk. > > Here, the term deploy refers to gathering all the qt dependencies (qt libs, > > plugins...) in a directory in order to generate the apk. > > > > The json file you talk about looks more to me to something linked to the > > deployment on the target. > > Any idea of the json file name when it works? > When run by qbs: > /home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/androiddeployqt.json > > But this time, QtC didn't try to run androiddeployqt, honestly the > behaviour seems to be unstable. > > adb install fails. It's possible that these sort of APK are not > supported by our AOSP. > I'll ask someone if this is supposed to work or not. From QtC: Initializing deployment to Android device/simulator Deploying to 150c980e8288de07 00:50:34: Running steps for project Neon Factory Tools... 00:50:34: Starting: "/home/chgans/Android/Sdk/platform-tools/adb -s 150c980e8288de07 install -r /home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/factory-testapp-0.0.apk" 00:50:34: The process "/home/chgans/Android/Sdk/platform-tools/adb" exited with code 255. When i copy/paste the command in a terminal, it doesn't fail: chgans@chgans-pc:~/Projects/neon-testapp$ /home/chgans/Android/Sdk/platform-tools/adb -s 150c980e8288de07 install -r /home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/factory-testapp-0.0.apk Performing Streamed Install Success chgans@chgans-pc:~/Projects/neon-testapp$ echo $? 0 Will report on QtC ML. Thanks again for your help! Chris > > Thanks, > Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qtc: Cannot find the androiddeploy Json file
On Fri, 15 May 2020 at 00:16, Raphael Cotty wrote: > > Hi, > The json file used in android_support.qbs is an input file used by the > androiddeployqt tool to generate the apk. > Here, the term deploy refers to gathering all the qt dependencies (qt libs, > plugins...) in a directory in order to generate the apk. > > The json file you talk about looks more to me to something linked to the > deployment on the target. > Any idea of the json file name when it works? When run by qbs: /home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/androiddeployqt.json But this time, QtC didn't try to run androiddeployqt, honestly the behaviour seems to be unstable. adb install fails. It's possible that these sort of APK are not supported by our AOSP. I'll ask someone if this is supposed to work or not. Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Android multiarch
On Fri, 15 May 2020 at 00:28, Christian Gagneraud wrote: > > On Fri, 15 May 2020 at 00:23, Raphael Cotty wrote: > > > > Hi, > > Can you try to use the QtApplication item instead of the CppApplication one? > > Hey, spot on! This solves the problem. Thanks a lot for that! Can you create and load multi-arch binaries with QtC + Qbs? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Android multiarch
On Fri, 15 May 2020 at 00:23, Raphael Cotty wrote: > > Hi, > Can you try to use the QtApplication item instead of the CppApplication one? Hey, spot on! This solves the problem. Now i have other problems, but this time it's QtC, QtC wants to run androiddeployqt again with --no-build --gradle --reinstall --device And it's adb pulling app_process, linker, libc.so, ... Weird stuff! Maybe i need to tweak a few things in QtC. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Android multiarch
On Fri, 15 May 2020 at 00:20, Raphael Cotty wrote:
>
> Hi,
> Can you enable androiddeployqt debug:
> Qt.android_support.verboseAndroidDeployQt
> And provide the output file?
00:21:53: Running steps for project Neon Factory Tools...
copying Qt resource templates [TestApp]
running androiddeployqt [TestApp]
/home/chgans/Programs/QtCommercial/5.14.2/android/bin/androiddeployqt
--output
/home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/deployqt_out
--input
/home/chgans/Projects/build-FactoryTools-Android_for_armeabi_v7a_arm64_v8a_x86_x86_64_Clang_Qt_5_14_2_for_Android-Debug/Debug_Android__54f9cea5714846ce/TestApp.93c1d015/androiddeployqt.json
--aux-mode --deployment bundled --android-platform android-28
--verbose
Cannot find application binary TestApp.
Process failed with exit code 2.
The following products could not be built for configuration
Debug_Android__54f9cea5714846ce:
TestApp
Error while building/deploying project Neon Factory Tools (kit:
Android for armeabi-v7a,arm64-v8a,x86,x86_64 (Clang Qt 5.14.2 for
Android))
When executing step "Qbs Build"
00:21:53: Elapsed time: 00:00.
And json:
{
"description": "This file was generated by qbs to be read by
androiddeployqt and should not be modified by hand.",
"qt": "/home/chgans/Programs/QtCommercial/5.14.2/android",
"sdk": "/home/chgans/Android/Sdk",
"sdkBuildToolsRevision": "28.0.3",
"ndk": "/home/chgans/Android/Sdk/ndk-bundle",
"toolchain-prefix": "llvm",
"tool-prefix": "llvm",
"useLLVM": true,
"ndk-host": "linux-x86_64",
"architectures":
{"x86_64":"x86_64-linux-android","arm64-v8a":"aarch64-linux-android"},
"qml-root-path": "/home/chgans/Projects/neon-testapp/sources/TestApp",
"stdcpp-path":
"/home/chgans/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/",
"application-binary": "TestApp"
}
Thanks,
Chris
> Thanks
> Raph
>
> Le jeu. 14 mai 2020 à 14:12, Christian Gagneraud a écrit :
>>
>> On Thu, 14 May 2020 at 23:34, Christian Gagneraud wrote:
>> >
>> > Hi there,
>> >
>> > As an experiment, i've just tried Qt-5.14, and this has enabled
>> > multi-arch on Android.
>> > I can select the list of architecture i want to support with
>> > qbs.architectures.
>> > This works for libraries, but my application is disabled:
>> > Error while handling 'TestApp'
>> > Product 'TestApp' had errors and was disabled.
>>
>> I've tracked the problem down into one library, I have an export item
>> that seems to be problematic.
>> For now i added an explicit dependency in the app, and removed the export.
>> Looks weird...
>>
>> But now androiddeployqt fails with:
>> Cannot find application binary TestApp
>> Don't know why it's not one of the libTestApp.so, ...
>>
>> 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] Android multiarch
On Thu, 14 May 2020 at 23:57, Richard Weickelt wrote:
>
>
> > As an experiment, i've just tried Qt-5.14, and this has enabled
> > multi-arch on Android.
> > I can select the list of architecture i want to support with
> > qbs.architectures.
> > This works for libraries, but my application is disabled:
> > Error while handling 'TestApp'
> > Product 'TestApp' had errors and was disabled.
> >
> > 3 of them, and that's all i get. I have 3 Depends that point to
> > internal libraries, maybe that's the smoking gun...
> > I have
> > multiplexByQbsProperties: ["architectures"]
> > qbs.architectures: ["arm64", "x86_64"]
> > For libs and apps.
> > I tried as well the 'usesNativeCode' but no success.
> >
> > Any idea what i'm missing?
>
> Can you show us some more code or even a minimal example?
Here is my app module:
CppApplication {
Depends { name: "Qt.core" }
Depends { name: "Qt.androidextras"; condition: qbs.targetPlatform
== "android" }
cpp.includePaths: [ project.sourceDirectory + "/sources", "." ]
cpp.cxxLanguageVersion: "c++14"
qbs.architectures: ["arm64", "x86_64"]
multiplexByQbsProperties: ["architectures", "profiles"]
Properties {
condition: qbs.targetPlatform == "android"
// https://x
Android.sdk.platform: "android-28"
Android.sdk.buildToolsVersion: "28.0.3"
Android.ndk.platform: "android-28"
// Apk
Android.sdk.packageName: "." + name.toLowerCase()
Android.sdk.versionName: project.versionName
Android.sdk.versionCode: project.versionCode
Android.sdk.apkBaseName: "factory-" + name.toLowerCase() + "-"
+ project.versionName
Android.sdk.manifestFile: sourceDirectory +
"/android/AndroidManifest.xml"
Android.sdk.keyStorePath: project.sourceDirectory + "/.jks"
Android.sdk.keyStorePassword: ":x"
Android.sdk.keyAlias: "xx"
Android.sdk.keyPassword: ":x"
// For debugging androiddeployqt issues, set this to true
// androiddeployqt is only use by qbs to collect dependencies
//Qt.android_support.verboseAndroidDeployQt: true
}
}
And my library module:
StaticLibrary {
Depends { name: "Qt.core" }
Depends { name: "Qt.androidextras"; condition: qbs.targetPlatform
== "android" }
cpp.includePaths: [ project.sourceDirectory + "/sources", "." ]
cpp.cxxLanguageVersion: "c++14"
multiplexByQbsProperties: ["architectures", "profiles"]
qbs.architectures: ["arm64", "x86_64"]
}
First time i'm using multi-arch, my understanding is that i should
have 1 APK that support these 2 archs
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Android multiarch
On Thu, 14 May 2020 at 23:34, Christian Gagneraud wrote: > > Hi there, > > As an experiment, i've just tried Qt-5.14, and this has enabled > multi-arch on Android. > I can select the list of architecture i want to support with > qbs.architectures. > This works for libraries, but my application is disabled: > Error while handling 'TestApp' > Product 'TestApp' had errors and was disabled. I've tracked the problem down into one library, I have an export item that seems to be problematic. For now i added an explicit dependency in the app, and removed the export. Looks weird... But now androiddeployqt fails with: Cannot find application binary TestApp Don't know why it's not one of the libTestApp.so, ... Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Android multiarch
Hi there, As an experiment, i've just tried Qt-5.14, and this has enabled multi-arch on Android. I can select the list of architecture i want to support with qbs.architectures. This works for libraries, but my application is disabled: Error while handling 'TestApp' Product 'TestApp' had errors and was disabled. 3 of them, and that's all i get. I have 3 Depends that point to internal libraries, maybe that's the smoking gun... I have multiplexByQbsProperties: ["architectures"] qbs.architectures: ["arm64", "x86_64"] For libs and apps. I tried as well the 'usesNativeCode' but no success. Any idea what i'm missing? Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Signing an Android APK
On Mon, 11 May 2020 at 20:10, Christian Gagneraud wrote: > > n Mon, 11 May 2020 at 19:43, Raphael Cotty wrote: > > > > Hi, > > > > Release keystore support is not implemented yet: > > https://bugreports.qt.io/browse/QBS-1546 > > > > Can you explain a bit more 'jks' keystore type? > > It turned out that it's just a file extension, the file format is the same. > I'm now able to sign and run the APK from QtC, i just changed the > hard-coded values. > > I've commented on QBS-1546. I'll open a change request, changes are quite trivial. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qtc: Cannot find the androiddeploy Json file
On Tue, 12 May 2020 at 18:37, Richard Weickelt wrote:
>
>
> > When i want to "run" on the device:
> > Initializing deployment to Android device/simulator
> > Deploying to 150c980e8288de07
> > Cannot find the androiddeploy Json file.
> > Error while building/deploying project Neon Factory Tools (kit:
> > Android for arm64-v8a (Clang Qt 5.12.8 for Android ARM64-v8a))
> > When executing step "Deploy to Android device"
> >
> > I think this happens only when i do cosmetic changes in my qbs files.
> > The only way to recover is to trigger a manual build, changing a
> > source file is not enough.
> >
> > Any idea what's goind on?
> > Looks to me this problem is on QtC side.
>
> A quick guess and without ever having built an Android project: The selected
> product is the application executable and thus, none of the subsequent rules
> is executed. Could that explain it? Have a look at
> https://code.qt.io/cgit/qbs/qbs.git/tree/share/qbs/module-providers/Qt/templates/android_support.qbs
> There is a rule that produces qt_androiddeployqt_input (the json file) which
> I guess is not requested when you press the "run" button. There are also
> subsequent rules responsible for the deployment.
>
> You could add one of the rule's output to your product type, although I
> guess there is a cleaner way of doing it.
>
> YourAndroidProduct {
> type: base.concat("bundled_jar")
> }
I've tried that and it didn't work :(
Maybe there's a problem on QtC side...
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Quick compiler with external library
Hi there,
The UI of my app is a separate static library, i would like too use
the quick compiler in release mode, like so:
Depends { name: "Qt"; submodules: "quick" }
Qt.quick.useCompiler: qbs.buildVariant == "release"
The problem is that on Desktop, it doesn't link due to the external
resource having a different name, so as a temporary workaround, i'm
using:
#ifdef NDEBUG
Q_INIT_RESOURCE(navico_ui_qtquickcompiler);
#else
Q_INIT_RESOURCE(navico_ui);
#endif
Not elegant, but will do for now.
But it doesnt work at runtime, i get errors like:
qrc:/navico/ui/TestModuleUiLoader.js:-1 No such file or directory
Same story with android, with the addition of:
E libTestApp.so: "unterminated string"
Not sure if it is related tho.
2 hours later:
I ended up comparing CMake vs Qbs generated cpp, and it turned out
that this is what i need to do with Qbs:
#ifdef NDEBUG
Q_INIT_RESOURCE(navico_ui_qtquickcompiler);
Q_INIT_RESOURCE(navico_ui_qrc_navico_ui_qtquickcompiler);
#else
Q_INIT_RESOURCE(navico_ui);
#endif
With CMake 'Q_INIT_RESOURCE(navico_ui);' works in both cases.
Looks like a bug to me. What do you think?
Chris
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Qtc: Cannot find the androiddeploy Json file
Hi there, Here is an error that happen every now and then, not sure if the problem is in QtC or not, so checking here first. When i want to "run" on the device: Initializing deployment to Android device/simulator Deploying to 150c980e8288de07 Cannot find the androiddeploy Json file. Error while building/deploying project Neon Factory Tools (kit: Android for arm64-v8a (Clang Qt 5.12.8 for Android ARM64-v8a)) When executing step "Deploy to Android device" I think this happens only when i do cosmetic changes in my qbs files. The only way to recover is to trigger a manual build, changing a source file is not enough. Any idea what's goind on? Looks to me this problem is on QtC side. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Signing an Android APK
n Mon, 11 May 2020 at 19:43, Raphael Cotty wrote: > > Hi, > > Release keystore support is not implemented yet: > https://bugreports.qt.io/browse/QBS-1546 > > Can you explain a bit more 'jks' keystore type? It turned out that it's just a file extension, the file format is the same. I'm now able to sign and run the APK from QtC, i just changed the hard-coded values. I've commented on QBS-1546. > About the non-repeatable errors, can you set > Qt.android_support.verboseAndroidDeployQt to true and provide the log? I have several issues, some might be due to QtC/Qbs integration, QtC is crashing sometimes as well... I've added the property, and let you know if i find something wrong. Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Signing an Android APK
On Mon, 11 May 2020 at 09:03, Raphael Cotty wrote: > > Hi, > > If you look at the sdk.qbs file in the Android module then you'll see that > you can provide a file for the keystore (pattern *.keytstore). > If not then qbs uses the default keystore file ($HOME/.android/debug.keystore > on Linux). Hum, looks like non debug signing is not implemented, keystore alias, password, ... are hardcoded in sdk/utils.js: prepareAaptPackage(). As well I had to add a tagger since our keystore has 'jks' file extension. The keystore comes with a property file, that contains all the details for the signing process, i don't know if it's standard or an in-house procedure. This could be a Freescale specific system too, our AOSP is based on the imx8 one. > Qbs also relies on androiddeployqt but only to gather the dependencies. The > generation of the apk package and the signing is done by qbs rules. I have non-repeatable errors in there, but a clean build seems to always work, i can generate APK in debug mode with default keystore. It crashes, but that's another story. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Signing an Android APK
Hi there, I'm experimenting with converting a project to Qbs. It is relatively small and is (so far) C++/Qt only. I have a few apps, and i need to generate APKs, and sign them. I couldn't find any mention of signing in Qbs docs, is this something supported? I currently (not using Qbs) rely on androiddeployqt, is this tool used by Qbs under the hood? Can i control it from Qbs? Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Improving qbs resolve performance
On Fri, 30 Aug 2019 at 11:01, Jochen Ulrich wrote: > I want to follow up on this topic: I had to check the archives and re-read the whole thread! > I created scripts to generate a Qbs project of a specified size. > Then, I created a few projects and measured the resolve time. Nice one. Maybe it would be nice to automate the data collection, this way it might be interesting to plot the various measurement versus tree depth and/or child count and/or product count. Just to see if we have something linear or logarithmic. Or maybe that's a job for a C++ benchmark... > Bottom line: > Exporting dependencies significantly slows down the resolving. > It is better to explicitly depend on the needed modules instead of having > another module export the dependency. > It’s a trade-off between having to write more “Depends” items vs. slower > resolving. Good to know, But the Export/Depends has definitely it's use, you don't need to track nested dependencies. Random thoughts: Is it realistic a depth of 9? Looking at your timings, it is still not clear where the bunch of the time is spent for the "withLeafExports/9-2-implicit" use case. Thanks, Chris ___ 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
On Fri, 9 Aug 2019 at 13:28, Иван Комиссаров wrote: > > 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 Isn't it what https://doc-snapshots.qt.io/ is for? Qbs master doc is available at https://doc-snapshots.qt.io/qbs/index.html Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs (way) faster than cmake (or benchmark issue)
On Tue, 23 Jul 2019 at 21:17, Иван Комиссаров wrote: > > 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. Writing such an article would require a bit more work in term of collecting and analysing data. As well, one would need to make sure that the comparison is fair, which i'm not certain it currently is at this stage. As well, to be complete, i would need to measure qmake perf and cmake+make as well. I would need to check qbs with the combineMocOutput option, ... As well a comparaison when using a hot ccache could be useful to measure overhead of the build system, ... The dependency graph export i would like to write has actually nothing to do with this perf comparaison and won't be useful. The 2 graphs (product/target based) have to be identical, this is about correctness not performance. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Graphviz export/generator
On Mon, 22 Jul 2019 at 21:25, Christian Kandeler wrote: > > On Sun, 21 Jul 2019 15:32:37 +1200 > Christian Gagneraud wrote: > > > Hi there, > > > > I would like to be able to export a (graphviz) graph of a project and > > i'm thinking about writing a new ProjectGenerator plugin for that. > > The first kind of graph would be a product dependency graph. > > > > Once i have access to the top level resolved project, AFAIU, the rest > > should be easy. As i can access all resolved products, and resolved > > products have a list of resolved product "dependencies". > > > > ProjectGenerator are executed after the project is resolved, good, but > > the API doesn't give access to the TopLevelProjectPtr, which seems to > > be my only available entry point. > > Any idea on how to tackle that? What would be the less intrusive API > > change that would allow RO access to build/graph dependency data from > > the generator plugins? > > You could just cheat by adding a helper function to the Project class; that'd > probably still be the cleanest. OK, might go for that then. > You might also be interested to know that we had something like that > and it got removed: https://codereview.qt-project.org/c/qbs/qbs/+/38596 > So perhaps check it out for hints on what not to do. Yes, that's the wrong granularity. That's why i want to plot the inter-product dependencies, not source/artifacts dependencies. And even with doing that the top graph might be too big. CMake can generates a per-target graph (w/ forward/reverse deps) and the whole thing, I might do something similar. I might use env variables to communicate all options/customisations. Any suggestion and/or wish list are welcome. Thanks, Chris > > > 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 (way) faster than cmake (or benchmark issue)
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). > > 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 > - build speed per job vs. job count > - cpu utilization per core vs. job count > - You're on your own, you're trying to proof something everyone know your're wrong. you have to spend enregy, not us. > > ___ > 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)
On Tue, 16 Jul 2019 at 18:29, Christian Gagneraud wrote: > > Hi there, > > I finally found time to start my qbs vs cmake build perf. > > What i found is that qbs beats cmake 'big time' on my build machine > and i was actually surprised, so surprised that i'm trying to find > where is the mistake. Here is a graph showing qtcreator build time vs number of parallel jobs, using cmake and qbs. Builds were done in a docker container (same for both), stock Ubuntu 19.04/amd64, all dependencies (inc. qbs tool and dev libs) installed using apt. Number of compilations were measured by generating a Clang compilation database and counting the number of entries: cmake: 2881 (2869) qbs: 4362 (2848) The first number is the number of compiler calls, the second number if the same but ignoring the pattern 'moc_'. Using 2 jobs: qbs: 26:30.78 cmake: 30:11.44 =>Cmake is 15% slower than qbs Using 56 jobs: qbs: 2:35.95 cmake: 4:33.79 => CMake is 75% slower than bqs 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. Chris qtcreator-build-time-cmake-vs-qbs.pdf Description: Adobe PDF document ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Graphviz export/generator
Hi there, I would like to be able to export a (graphviz) graph of a project and i'm thinking about writing a new ProjectGenerator plugin for that. The first kind of graph would be a product dependency graph. Once i have access to the top level resolved project, AFAIU, the rest should be easy. As i can access all resolved products, and resolved products have a list of resolved product "dependencies". ProjectGenerator are executed after the project is resolved, good, but the API doesn't give access to the TopLevelProjectPtr, which seems to be my only available entry point. Any idea on how to tackle that? What would be the less intrusive API change that would allow RO access to build/graph dependency data from the generator plugins? Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Improving qbs resolve performance
On Sun, 14 Jul 2019 at 17:30, Christian Gagneraud wrote: > Looking at valgrind/callgrind data, it seems that the hot path is a > loop, here is a simplified tree with the final loop > - resolveProjectFromScratch() > - loadProject() > - handleTopLevelProject() > - setupProductDependencies() > - 0 - resolveDependencies() > - 1 - resolveDependsItem() > - 2 - loadModule() > - 3 - instanciateModule() > - 4 - goto 0 There is indeed a cache system, but it is only enable in very few location (Using EvalCacheEnabler). And that's one of the hot spots: Evaluator::property() - 26% of the fetched instructions while resolving the qbs project. I need to test with resolving QtCreator. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs resolve, multi-threaded or not?
Hi there, When I run qbs resolve (on a 8 cores machine), i can see 3 qbs threads, and only 2 are busy (100% CPU). Is there partial parallelisation of the resolve phase? Why are there only 2 threads busy? why not 8? In a previous email Christian said that the resolve phase was not parallelised. Sorry for the dumb question, i'm just trying to understand some of the Qbs internals. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dump-nodes-tree broken?
On Wed, 17 Jul 2019 at 23:52, Christian Kandeler wrote: > > On Wed, 17 Jul 2019 23:41:54 +1200 > Christian Gagneraud wrote: > > > I'm trying to use dump-nodes-tree with qbs 1.13.1 (from QtC), and i > > get nothing except a message 'Restoring build graph from disk'. > > I've tried 'qbs dump-nodes-tree' and 'qbs dump-nodes-tree -p > > qtcreator', still the same.. > > Is there any special things that need to be done prior using it? > > You need to built first. The nodes are not known in advance. Ahhh! Thanks, it works now. That's weird really, the build graph is on disk, and this tool 'Dumps the nodes in the build graph to \c stdout.'. I was expecting this tool to simply pretty-print the build graph file.Is there a way to achieve that? Looking at the output of dump-nodes-tree and the source code, i kind of start to kind of understand what's going on... :) Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dump-nodes-tree broken?
On Wed, 17 Jul 2019 at 23:41, Christian Gagneraud wrote: > > Hi there, > > I'm trying to use dump-nodes-tree with qbs 1.13.1 (from QtC), and i > get nothing except a message 'Restoring build graph from disk'. > I've tried 'qbs dump-nodes-tree' and 'qbs dump-nodes-tree -p > qtcreator', still the same.. > Is there any special things that need to be done prior using it? Is it > actually broken? > PS: I've never used this tool before. > > Using the debugger, i can see that NodeTreeDumper::start() loops on > all the product, but not on the 'artifacts', > p->buildData->rootArtifacts() returns nothing. Actually TypeFilter is constructed with non-empty m_roots, but it seems the iterator is broken. > > Any idea what i'm doing wrong? > > Thanks, > Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] dump-nodes-tree broken?
Hi there, I'm trying to use dump-nodes-tree with qbs 1.13.1 (from QtC), and i get nothing except a message 'Restoring build graph from disk'. I've tried 'qbs dump-nodes-tree' and 'qbs dump-nodes-tree -p qtcreator', still the same.. Is there any special things that need to be done prior using it? Is it actually broken? PS: I've never used this tool before. Using the debugger, i can see that NodeTreeDumper::start() loops on all the product, but not on the 'artifacts', p->buildData->rootArtifacts() returns nothing. Any idea what i'm doing wrong? Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs (way) faster than cmake (or benchmark issue)
On Tue, 16 Jul 2019 at 18:29, Christian Gagneraud wrote: > The compiler flags are not the same, but not so far off: > Qbs: -g -O0 -Wall -Wextra -m64 -pipe -fexceptions -fvisibility=hidden > -fvisibility-inlines-hidden -fPIC > CMake: -g -O0 -std=c++14 -fvisibility=hidden > -fvisibility-inlines-hidden -fPIC -fstack-protector-strong -Wformat > -Wformat-security Maybe the use of -pipe has noticeable effects. I'm currently running builds with incremental parallel jobs and i record the load average history. When building with Qbs I can clearly see "stairs" (except for high parallel jobs), with CMake it's difficult to spot as if there was a lot of noise. As well, i've now disabled building unit tests and qbs when building with qbs, the comparison should now be more fair: time qbs -f ../qtcreator.qbs -j $jobs profile:qt-5-12-2 project.withAutotests:false vs cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS_DEBUG="-O0 -g" -G Ninja .. time ninja -j $jobs Qbs builds QtCreator in 2:46, ninja in 4:55 (not counting the initial cmake call which would add 5+ seconds), the ratio is 0.56, basically Qbs is twice as fast when using all the available cores on this particular machine/env. I think i'll try to match the compiler flags exactly, and use tmpfs for /tmp and the build dir. This should remove most of the IOs "noise" What i've noticed so far is that ninja use a shell to run the compiler, and AFAIU, ninja calls "cmake -E cmake_autogen", to handle Qt's moc. Weird Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs (way) faster than cmake (or benchmark issue)
On Tue, 16 Jul 2019, 19:00 Oswald Buddenhagen, wrote: > On Tue, Jul 16, 2019 at 06:29:35PM +1200, Christian Gagneraud wrote: > > $ time qbs -f ../qtcreator.qbs profile:qt-5-12-2 > > user96m51.927s > > sys 19m52.059s > > > > $ time ninja > > user70m58.028s > > sys 23m9.238s > > > these system time figures appear *wy* too high to me. something > funny appears to be going on with your kernel. > Interesting remark, the builds were done inside docker container. Still, they might be good tho, this machine has 28 cores/56 threads. Nonetheless, wall time clearly show that qbs build way more stuff than cmake, and does this in less time. I might collect the load average while building, which will show that Qbs is more efficient. As well, the build time Vs job count graph might give clue. 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] Qbs (way) faster than cmake (or benchmark issue)
Hi there, I finally found time to start my qbs vs cmake build perf. What i found is that qbs beats cmake 'big time' on my build machine and i was actually surprised, so surprised that i'm trying to find where is the mistake. Basically, qbs builds more stuff than cmake in less time (!?!) Build server: - Dual Xeon Gold 6132 - 256GB RAM - 2TB RAID-something SSD Total cores: 28, total threads: 56 $ time qbs -f ../qtcreator.qbs profile:qt-5-12-2 real3m6.159s user96m51.927s sys 19m52.059s $ du -sh 18G . $ find . -name '*.o' | wc -l 4917 $ find default/install-root/ -name '*.so' | wc -l 93 $ time cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS_DEBUG="-O0 -g" -G Ninja .. real0m3.281s user0m1.960s sys 0m1.327s $ time ninja real4m51.174s user70m58.028s sys 23m9.238s $ du -sh 4.9G. $ find . -name '*.o' | wc -l 2881 $ find . -name '*.so' | wc -l 88 The compiler flags are not the same, but not so far off: Qbs: -g -O0 -Wall -Wextra -m64 -pipe -fexceptions -fvisibility=hidden -fvisibility-inlines-hidden -fPIC CMake: -g -O0 -std=c++14 -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -fstack-protector-strong -Wformat -Wformat-security Qbs wall time: 3m6 CMake wall time: 4m54 Qbs CPU time = 97 + 20 = 107 minutes CMake CPU time = 71 + 23 = 94 minutes While it was building, htop showed that Qbs made a better CPU usage than CMake. Qbs tend to load all the CPU at maximum for almost the entire duration of the build while Cmake had lot of gaps in term of CPU usage. As well, somehow qbs did more stuff, since it populated the install-root, where-as cmake has a sort of "in-place" install-root (build dir is install-root) If i have more time, i would like to explore: - https://lists.qt-project.org/pipermail/qbs/2019-May/002408.html - https://lists.qt-project.org/pipermail/qbs/2019-May/002419.html - make a graph with build time vs job counts - add cold/warm ccache - use RAM disk for ccache store and build directory I did a similar benchmark for our project, it showed that our build system (qmake) was unable to cope with more than 6 cores, enabling dep tracking improved the situation but was still not scalable. CMake (+Ninja) is better than qmake, but i never ran a comparison with Qbs. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Improving qbs resolve performance
On Fri, 12 Jul 2019 at 00:45, Christian Kandeler
wrote:
>
> On Thu, 11 Jul 2019 12:18:30 +
> Maximilian Hrabowski wrote:
>
> > I have a fairly large project with a root projects that pulls in several
> > SubProjects, altogether with unit tests its about 313 qbs files that are
> > pulled in.
>
> The number of project files is not all that important by itself. Qt Creator,
> for instance, has a comparable number, and resolves much faster than your
> project.
>
> > Let root.qbs be the root qbs file of my project and depend.qbs a subproject
> > that many other subprojects depend on.
> >
> > With a single profile and single config I encounter the following duration
> > for qbs resolve on my macbook pro with 12 logical CPUs:
> >
> > 1) qbs resolve (clean, new build directory, so includes creating a build
> > graph): ~1m 25s
>
> qbs --log-time might give some hints as to where that time is spent.
I checked out my old experimental branch and compared resolving qtc
and this project:
QtC:
Qt was set up successfully.
Project file loading and parsing took 161ms.
Preparing products took 1ms.
Setting up product dependencies took 4s, 826ms.
Setting up transitive product dependencies took 930ms.
Handling products took 5s, 160ms.
Running Probes took 2s, 190ms.
1916 probes encountered, 8 configure scripts executed,
1901 re-used from current run, 0 re-used from earlier run.
Property checking took 689ms.
Activity 'ModuleLoader' took 11s, 433ms.
My project:
Qt was set up successfully.
Project file loading and parsing took 100ms.
Preparing products took 0ms.
Setting up product dependencies took 1m, 37s, 54ms.
Setting up transitive product dependencies took 1s, 74ms.
Handling products took 17s, 925ms.
Running Probes took 1s, 799ms.
804 probes encountered, 5 configure scripts executed,
797 re-used from current run, 0 re-used from earlier run.
Property checking took 194ms.
Activity 'ModuleLoader' took 1m, 55s, 496ms.
So the obvious difference is "Setting up product dependencies".
Looking at valgrind/callgrind data, it seems that the hot path is a
loop, here is a simplified tree with the final loop
- resolveProjectFromScratch()
- loadProject()
- handleTopLevelProject()
- setupProductDependencies()
- 0 - resolveDependencies()
- 1 - resolveDependsItem()
- 2 - loadModule()
- 3 - instanciateModule()
- 4 - goto 0
This match with "my gut feeling" expressed previously, projects with
complex dependency tree are penalised.
In this particular case, a cache system would greatly help, or maybe
there is one in place, and the project files do something that
invalidate this cache...
Chris
>
> > 2) qbs resolve (no changes): ~0.5 s
> > 3) qbs resolve after "touch root.qbs" (restores build graph): ~1m 15 s
> > 4) qbs resolve after “touch depend.qbs” (restores build graph): ~1m 15s
> >
> > From the durations i would expect that there is some room for improvement.
> > To me it seems (by looking at 3 and 4) that qbs rebuilds the whole build
> > graph if it detects any change to any qbs file in the project.
>
> Yes, there is no partial re-resolve.
>
> > If this is the case i wonder how difficult it would be to improve this and
> > what the right approach would be. Maybe looking at “Depends {}” would be
> > enough to determine the “dirty path”.
>
> I suspect this is hopeless. In general, there are too many possible
> interdependencies for a statement like "if file x has changed, we know what
> only product y can be affected". At the very least, much more now-temporary
> data from the resolve stage would have to be stored for such logic to work.
>
> > Fortunately QtC 4.9.x seems to cache something now since opening a qbs
> > project will no longer cause a full resolve.
>
> I don't think anything has changed there recently. qbs re-resolved when it
> thinks that's necessary, i.e. a project file or a property or the environment
> has changed.
>
> > Any ideas or maybe even someone looking at that already?
>
> The only remote possibility that I see is somehow making use of concurrency
> when resolving, e.g. have one thread per product. It would not be trivial,
> though, due to inter-product dependencies etc; also, you'd need a dedicated
> script engine per thread. I don't remember the details, but whenever I though
> about this topic, I quickly stopped again after examining what we do in the
> ModuleLoader, which is by far the most expensive stage of project resolving
> these days, and thus the only one worth optimizing.
> (I certainly don't want to to dissuade anyone from trying, it's just that you
> need to be prepared for a disappointing outcome. For a much lower-hanging
> fruit in the area of performance improvement, take a look at
> https://bugreports.qt.io/browse/QBS-1448.)
>
>
> Christian
> ___
>
Re: [Qbs] Improving qbs resolve performance
On Sat, 13 Jul 2019 at 00:48, Christian Kandeler wrote: > > On Fri, 12 Jul 2019 12:05:48 + > Maximilian Hrabowski wrote: > > > >> I have a fairly large project with a root projects that pulls in several > > >> SubProjects, altogether with unit tests its about 313 qbs files that are > > >> pulled in. > > > > > > The number of project files is not all that important by itself. Qt > > > Creator, for instance, has a comparable number, and resolves much faster > > > than your project. > > > > Can you give any guidance what to avoid, i.e. what makes resolving slow if > > QtC is much faster resolved? > > Nothing beyond the obvious, such as calling external processes on the > right-hand side of properties (but you should get warnings for that anyway). > Related: If you have probes, be sure not to trigger them inadvertently. > Excessive use of wildcards is also discouraged. > This is what comes to mind spontaneously. What about complex inter-dependencies? I tried once to convert a legacy project. This was quite big (bigger than QtC) and complex (in term of public/private inter-dependencies), and i do remember running into "performance" issues. I do agree that QtC is faster to resolve, but it is quite "clean", and so facilitate the job of the build sytem in that respect. Just imagine a chain of dependencies, let say an app has direct dependency to say 20 static libs, in turn these libs have a "meander" of inter-dependencies, with say the longest chain being 10 or more item longs, and the final number of libs to (directly or indirectly) link is something around 100. On top of that let's add "lots" of system dependencies (eg, 10+ Qt modules, 10's of lower level libs, ...) Could that cause serious slow down of the resolving? The project i'm talking about is so big and complex, that we hit all the walls. For example we manage to get a 32bits linker run out of address space, we solved the issue by tweaking/massaging the linker flags, but still it can take one to 2 minutes just to link the final executable. So if ld (bfd or gold) fight with linking such an executable, could it be that Qbs fight with resolving it's build graph? What about the cpp and the moc scanner? if you have a lot of "moc'able" source files, with complex/crazy include hierarchy, could this seriously impact the resolve work? Pure speculation here, randomly picked: I'm not familiar with Qbs internals, but just stumble on the "Opaq" struct in cppscanner.cpp, which has a "QList includedFiles; " member. Given how lists are not CPU cache friendly, could this sort of "minor details" greatly impact Qbs performance when trying to resolve "poorly" organized giant projects? With modern CPU, cache locality is paramount. > (I certainly don't want to to dissuade anyone from trying, it's just that you > need to be prepared for a disappointing outcome. For a much lower-hanging > fruit in the area of performance improvement, take a look at > https://bugreports.qt.io/browse/QBS-1448.) (pure speculation here). Is the build graph first built/resolve in-memory, or is it built/visited on-disk? If the former, then it is unlikely the bottle neck here, if the later, that might indeed be a good lead. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to reload a parent project after inserting a sub-project
On Mon, 8 Jul 2019 at 22:09, Christian Kandeler wrote: > I would not bother with any of that. Just update the files. Any halfway > decent IDE will have a watch on the qbs files and re-resolve the project. I'm > not ruling out that manually manipulating the build graph (as we do for file > updates) is possible, but it seems quite ambitious. > > > > > Yes indeed, it looked quite complicated to me. Sounds like a good plan > > to use QtC's watch system > > Actually, a watch system isn't even needed at all, as the IDE knows that it's > told qbs to update the files. So it can just manually schedule a re-parse. In > fact, we actively switch off the watcher for such cases, to suppress the "do > you want to reload" dialog. I see, but for some reason, it's not auto-reloading, will investigate further, thanks for the tip. > > > i guess the only thing I'm missing is > > saving the edited file on the QtC side, or maybe it's better to do > > that on Qbs side (but wouldn't be consistent with group/file > > add/remove). > > I'm pretty sure we do save the files on the qbs side there. Yes, as Qbs unit tests show, it obviously does happen, but within QtC something is missing... Interesting. Thanks for sharing. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to reload a parent project after inserting a sub-project
On Mon, 8 Jul 2019 at 22:09, Christian Kandeler wrote: > I don't know what you mean by "simulating a full project reload". Lots of > tst_api test cases do project reloads. I just meant a convenience function that would handle: project = qbs::Project(); job.reset(nullptr); buildJob.reset(nullptr); removeBuildDir(setupParams); setupParams.setProjectFilePath( QDir::cleanPath(m_workingDataDir + "/project-editing/toplevelproject.qbs")); job.reset(project.setupProject(setupParams, m_logSink, nullptr)); waitForFinished(job.get()); QVERIFY2(!job->error().hasError(), qPrintable(job->error().toString())); So far, that how my "full reload" is implemented (read: copy/pasted), and i will want to do that b/w 5 and 10 times. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] [RFC] Add a clang-format config file to qbs repo
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
Re: [Qbs] How to reload a parent project after inserting a sub-project
On Mon, 8 Jul 2019 at 20:50, Christian Kandeler wrote: > > On Mon, 8 Jul 2019 18:08:25 +1200 > Christian Gagneraud wrote: > > > I'm back on https://codereview.qt-project.org/c/qbs/qbs/+/260217, i > > decided that I should get that done and tested before I move on > > QtCreator integration. > > Conceptually, it works, i added a test that check that a sub-project > > is correctly inserted, but for now, i need to re-setup the top project > > using SetupProjectJob (in tst_api.cpp). > > I would not bother with any of that. Just update the files. Any halfway > decent IDE will have a watch on the qbs files and re-resolve the project. I'm > not ruling out that manually manipulating the build graph (as we do for file > updates) is possible, but it seems quite ambitious. > Yes indeed, it looked quite complicated to me. Sounds like a good plan to use QtC's watch system, i guess the only thing I'm missing is saving the edited file on the QtC side, or maybe it's better to do that on Qbs side (but wouldn't be consistent with group/file add/remove). I need to do some minor cleanup on my Qbs review, i really would like to have some tests, even if they are basic. I was thinking about adding a function to tst_api that would simulate a full project reload, this would allow me to verify that i can add and remove references to the toplevel project and check for error cases, maybe another simple test to make sure it works for nested project. Any objection with that approach? Thanks, Chris ___ 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
On Mon, 8 Jul 2019 at 18:15, Vincent Hui wrote: > > Hi Richard and Ivan, > > I tried a project called qbs-autoproject that can generate qbs files > automatically. I modified the example to try whether multiple executables can > be generated without adding CppApplication by myself, the result was that > multiple executables were generated successfully without adding > CppApplication by myself on Ubuntu 18.04. After qbs-autoproject had been > parsed in Qt Creator, qbs-autoproject/.autoproject/example.autoproject.qbs > was generated. Two executables "app1d" and "app2d" were generated when the > project was built. > > You can try the example I modified, the project is attached. > > The next thing I want to do is investigating whether qbs-autoproject can be > used in complicated projects. Are you trying to convert an existing project that use a different build system, or are you trying to create qbs files out of a tree of source files? If you're project is not big, IMHO, it will be faster to write your qbs file by hand, that's the only way to learn. Start with something simple, and then build up slowly by adding more libs, apps, plugins, refactor your files as you start to copy/paste too much, etc... As mentioned by Ivan, if you want to learn how to deal with complicated projects, the best is to check QtCreator's use of Qbs and Qbs' use of Qbs itself. You'll see everything you need to know (and more!) Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] How to reload a parent project after inserting a sub-project
Hi there, I'm back on https://codereview.qt-project.org/c/qbs/qbs/+/260217, i decided that I should get that done and tested before I move on QtCreator integration. Conceptually, it works, i added a test that check that a sub-project is correctly inserted, but for now, i need to re-setup the top project using SetupProjectJob (in tst_api.cpp). So far, i managed to find the parent ResolvedProject (the only data structure where sub-projects is writable. The problem is that subProjects are themselves ResolvedProject. So given a parent ProjectData I can insert a sub-project into Qbs code, now i need to create a ResolvedProject from this new sub-project Qbs file, so that i can append it to the parent's ResolvedProject's subProjects, and hopefully I will just have to call updateData. Unfortunately ProjectResolver doesn't expose anything interesting, tho, the private resolveTopLevelProject() sounds very interesting... a bit too hackish maybe. It feels wrong to have to create a ProjectUpdateContext and create a ResolvedProject out of that, all "by hand", surely there's some code somewhere that can be re-used. Any thoughts on how to get going from here? Any help or point out would be greatly appreciated. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Is there a feature similar with cmake option?
On Sat, 6 Jul 2019 at 02:49, Vincent Hui wrote: > > Hi Richard, > > Thank you for your reply, > > Sorry, I am not a cmake expert. I cannot explain what CMakeCache.txt is used > for. What I can tell is that cmake users either edit CMakeCache.txt directly > to change values of options or use CMake GUI to build a project in > interactive mode, I am thinking whether we need qbs GUI in order to let > users build a project in interactive mode. This CMakeCache.txt can be problematic, sometimes with CMake if you want to reconfigure your project you need to wipe out this file and sometimes the whole build directory. AFAIU, this is similar to qmake stash and the so-called "site" files of GNU autotools. > Why GUI is needed to let users build projects in interactive mode in cmake. > " Using CMake to build a project in non-interactive mode is a simple process > if the project does not have many options. For larger projects like VTK, > using ccmake, cmake -i, or CMakeSetup is recommended. This is because as you > change options in the CMakeCache.txt file, cmake may add new entries to that > file. It can be difficult to know when to stop the run cmake, edit the cache > file cycle without the aid of an interface." > https://cmake.org/runningcmake/ Having to re-run cmake all the time is a real pain, and user experience with qtcreator goes down big time when you have a big project as it introduce minute long delay and freeze the UI for 5 to 10 seconds. As well soemetimes qtcreator get stuck, and you have to re-run cmake "manually" (hitting ctrl-B doesn't work anymore). But it sometimes get even worth, there are situation where you need to close/reopen your project, and unfortunately you sometimes need to *restart* qtc, due to cmake work dir being completely broken. All of the above happens when you edit various part of your cmake files, which is often the case of a project maintainer that tries to add new features to a project. I'm quite frustated with that, but i'm patient and hope this will improve over time. Initially i didn't like this GUI thing, but latter learned to appreciate its value, for example QtCreator gives you access to all these options in the project's build settings, and use the right widget for the "option" editor. It is very valuable because as a project maintainer it allows you to make it easy for other developers to play with these options. You can define the type of the options (limited set: bool, file, dir and strings), default value, and a help string. These options don't belong to profiles as they are project specific. Having a way to expose project specific options with qbs would be a nice thing. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
On Thu, 16 May 2019 at 11:24, Иван Комиссаров wrote: > > 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/ 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… can QList -> QVector be automated? Or does it has to be done on a case by case? I have a python script to do "mass but targeted" clang/clazy auto-fixit. There is https://github.com/KDE/clazy/blob/master/docs/checks/README-inefficient-qlist.md But it doesn't offer a fixit :( Concerning the QSharedDataPointer classes are not marked as Q_MOVABLE_TYPE, could clazy detect/fix these as well? > 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). Moving to QVector seems easier, at least as a first test. But we would need performace regression testing to see if it really speed up things. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
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] Who compared build times of Qt Creator with CMake and qbs?
On Thu, 16 May 2019 at 02:01, Christian Gagneraud wrote: > > On Thu, 16 May 2019 at 01:45, Orgad Shaneh wrote: > > > > I compared qbs and cmake/ninja, and got these results (Debug build, no > > QbsPM and no Clang): > > > > Notice that qbs builds unit tests, which cmake doesn't. > > > > time qbs -f ../qt-creator/qtcreator.qbs profile:qt-5-11-1 > > modules.cpp.compilerWrapper:ccache > > cold ccache: > > real5m26.149s > > user125m3.443s > > sys 16m55.134s > > > > warm cache: > > real1m40.335s > > user17m20.419s > > sys 4m12.409s > > > > 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 > > > > Thanks for reporting, i'm planning to run my own benchmark as well, > not to state who's the winner, just for curiosity. > One important metric IMHO is the ratio sys/user, as it shows I/O > bottlenecks (esp. relevant when doing debug builds with hot ccache). > In my setup i will use ram disks for ccache and build dir (source dir > has nearly no effects) > It used to be my typical config (had to fight for memory tho), until i > got a new machine with NVRam as mass storage. It's almost as fast as > ramdisks. > > 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". a `du -shc build-dir` would be interesting too. > > Chris ___ 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?
On Thu, 16 May 2019 at 01:45, Orgad Shaneh wrote: > > I compared qbs and cmake/ninja, and got these results (Debug build, no QbsPM > and no Clang): > > Notice that qbs builds unit tests, which cmake doesn't. > > time qbs -f ../qt-creator/qtcreator.qbs profile:qt-5-11-1 > modules.cpp.compilerWrapper:ccache > cold ccache: > real5m26.149s > user125m3.443s > sys 16m55.134s > > warm cache: > real1m40.335s > user17m20.419s > sys 4m12.409s > > 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 > Thanks for reporting, i'm planning to run my own benchmark as well, not to state who's the winner, just for curiosity. One important metric IMHO is the ratio sys/user, as it shows I/O bottlenecks (esp. relevant when doing debug builds with hot ccache). In my setup i will use ram disks for ccache and build dir (source dir has nearly no effects) It used to be my typical config (had to fight for memory tho), until i got a new machine with NVRam as mass storage. It's almost as fast as ramdisks. 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". Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
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] Who compared build times of Qt Creator with CMake and qbs?
On Tue, 14 May 2019 at 23:10, Joerg Bornemann wrote: > > On 5/14/19 12:04 PM, Christian Gagneraud wrote: > > On Tue, 14 May 2019 at 22:02, Joerg Bornemann wrote: > >> > >> On 5/14/19 10:57 AM, Tobias Hunger wrote: > >> > >>> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is > >>> linked > >>> into Creator, that will also need to be ported to Qt 6 to stay feasible. > >> > >> ...which shouldn't pose a challenge at all given that Qt 6 is to keep > >> source incompatible changes minimal. > > > > Unless they drop QtScript... > > This is bound to happen anyway. It can be forked. But can it be maintained? Can it be ported to Qt6? By 'can', i mean who will do that? Who has the time, the resources? Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
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 Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
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 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 70 QtCore/qstring.h 67 QtCore/qstringlist.h 54 QtCore/qdir.h 40 QtCore/qfileinfo.h 39 QtCore/qvariant.h 37 QtCore/qhash.h 30 QtCore/qprocess.h 28 QtCore/qshareddata.h 28 QtCore/qobject.h 26 QtScript/qscriptvalue.h 25 QtCore/qlist.h 25 QtCore/qcoreapplication.h 24 QtCore/qfile.h 20 QtScript/qscriptengine.h 20 QtCore/qglobal.h 18 QtCore/qmap.h 17 QtCore/qdebug.h 14 QtCore/qbytearray.h 13 QtCore/qtimer.h 12 QtCore/qtextstream.h 11 QtCore/qregexp.h 11 QtCore/qdiriterator.h 10 QtScript/qscriptable.h 8 QtCore/qt_windows.h 7 QtCore/quuid.h 7 QtCore/qdatastream.h 6 QtCore/qsettings.h 5 QtScript/qscriptvalueiterator.h 5 QtScript/qscriptclass.h 5 QtCore/qtemporaryfile.h 4 QtScript/qscriptcontext.h 4 QtCore/qthread.h 4 QtCore/qloggingcategory.h 4 QtCore/qcryptographichash.h 3 QtCore/qmetatype.h 3 QtCore/qjsonobject.h 3 QtCore/qjsondocument.h 3 QtCore/qflags.h 3 QtCore/qdatetime.h 2 QtScript/qscriptstring.h 2 QtScript/qscriptprogram.h 2 QtScript/qscriptclasspropertyiterator.h 2 QtNetwork/qlocalsocket.h 2 QtGui/qtextcursor.h 2 QtCore/qxmlstream.h 2 QtCore/qvarlengtharray.h 2 QtCore/qlibrary.h 2 QtCore/qjsonarray.h 2 QtCore/qeventloop.h 2 QtCore/qelapsedtimer.h 2 QtCore/qabstractitemmodel.h 1 QtXml/qdom.h 1 QtWidgets/qmessagebox.h 1 QtWidgets/qmenu.h 1 QtWidgets/qmenubar.h 1 QtWidgets/qmainwindow.h 1 QtWidgets/qapplication.h 1 QtWidgets/qaction.h 1 QtNetwork/qsslcertificate.h 1 QtNetwork/qsslcertificateextension.h 1 QtNetwork/qlocalserver.h 1 QtGui/qtextobject.h 1 QtGui/qtextdocument.h 1 QtGui/qkeysequence.h 1 QtGui/qevent.h 1 QtGui/qbrush.h 1 QtCore/qvector.h 1 QtCore/qurl.h 1 QtCore/qtextcodec.h 1 QtCore/qtemporarydir.h 1 QtCore/qregularexpression.h 1 QtCore/qpoint.h 1 QtCore/qpair.h 1 QtCore/qnumeric.h 1 QtCore/qlockfile.h 1 QtCore/qiodevice.h 1 QtCore/qendian.h 1 QtCore/qcommandlineparser.h 1 QtCore/qcommandlineoption.h 1 QtCore/qbytearraymatcher.h 1 QtCore/qbytearraylist.h 1 QtCore/private/qcore_mac_p.h chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name '*.[hc]*' | wc -l 482 Chris ___ 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?
On Tue, 14 May 2019 at 22:02, Joerg Bornemann wrote: > > On 5/14/19 10:57 AM, Tobias Hunger wrote: > > > The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is > > linked > > into Creator, that will also need to be ported to Qt 6 to stay feasible. > > ...which shouldn't pose a challenge at all given that Qt 6 is to keep > source incompatible changes minimal. Unless they drop QtScript... Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Donation to QBS developers/maintainers/contributes
On Tue, 14 May 2019 at 21:46, Иван Комиссаров wrote: > > +1 > > 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. Chris ___ 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?
On Tue, 14 May 2019 at 21:32, Tobias Hunger wrote: > > On Tue, 2019-05-14 at 21:06 +1200, Christian Gagneraud wrote: > > From the change description: > > All plugins have been converted to CMake, with the following exceptions: > > - qbsprojectmanager > > > > Any reason why? > > There is no find_package script for qbs that we can just use. > > Don't panic, it will be there. phew! ;) Are you planning to remove qbs as a submodule? That's very handy when you work on QtC/Qbs integration Chris ___ 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?
On Tue, 14 May 2019 at 20:58, Tobias Hunger wrote:
>
> On Tue, 2019-05-14 at 10:04 +0200, Ola Røer Thorsen wrote:
> > I'd like to know if Qt Creator will phase out Qbs support completely,
> > seeing the comments and summary in that commit ("Qbs is dead"). Would be
> > really bad for at least my team, if they did.
>
> That "qbs is dead" was me, so I guess I need to clarify that statement:
Quote:
Qbs is dead, I won't bother collecting that data:-) When I benchmarked
qbs against cmake they were in the same ballpark though
I will run a comparison, that is an interesting piece of information.
> I do not see qbs as an option to build Qt Creator with going forward. My plan
> is
> to built creator with cmake and to remove both the qbs as well as the qmake
> build systems from the Qt Creator sources.
>
> Note that this is about the build system used to *build Qt Creator with*, not
> about *build systems supported by Qt Creator*. I would personally like to keep
> qbs supported as a build system for projects in Qt Creator for as long as it
> is
> feasible.
From the change description:
All plugins have been converted to CMake, with the following exceptions:
- qbsprojectmanager
Any reason why?
Chris.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] [Fun] Found another "build system" called 'qbs'
Hi there, Just stumble upon that project called 'qbs' qbs - Quick (and dirty) build system: https://gitlab.com/nonnymoose/qbs Completely different approach and use-case, but i thought that's funny that such a project exists with that name. Chris ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Future of Qbs
On Wed, 31 Oct 2018 at 23:57, Timur Kristóf wrote: > > On Wed, 2018-10-31 at 20:45 +1300, Christian Gagneraud wrote: > > > > > > 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 looks to me a bit early to make some plan, give people enough time > > to digest this. > > I'd like to know if the decision to obsolete Qbs is final, or is there > a chance that you guys might still change your mind? > > Taking a look at the blog bost I see a lot of salty comments coming > from Qbs users. For the record, the blog post in question can be found at http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/ Chris PS: completely off-topic, has qt.io (aka the Qt Company) ever heard of https everywhere [1]? The Qt mailing list archive is currently serving plain HTTP over HTTPS port [2]. And is redirecting http to https... [1] https://www.eff.org/https-everywhere [2] http://lists.qt-project.org/ ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
On Wed, 31 Oct 2018 at 18:51, Richard Weickelt wrote: > > 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 looks to me a bit early to make some plan, give people enough time to digest this. Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] QBS usage
On 18 June 2018 at 20:58, Christian Kandeler wrote: > On Mon, 18 Jun 2018 11:01:10 +1200 > Christian Gagneraud wrote: > >> Last thing, Qbs has built-in support for different compilers/linkers, >> this is nice b/c I can just express my toolchian flags in a toolchain >> agnostic way, but... >> - Qbs will have to continuously catch up with the fast moving toolchain world >> - Users depend on Qbs core team to gain support for exotic compilers > > How so? You can just provide your own cpp backend, if you wish. Or provide a > patch to extend an existing one. Sorry wrote the email in a rush, "Qbs core team" => Qbs developer. Of course qbs users can contribute, but users don't always have time/willing to dig into Qbs source code and hack it around. How can i provide my own backend? Do I have to write code, and build it against Qbs source tree? Or can it be provided via a local qbs file? Chris > > > 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] QBS usage
On 16 June 2018 at 15:58, Tino Pyssysalo wrote: > I’d like to know, if you have used or are using QBS as a build system in > real projects and all feedback and suggestions would be mostly welcome. This > is a great opportunity to affect the future of QBS. Obviously, we are > closely following QBS issues in Jira and in this mailing list, so there’s no > need to report any known issues, unless you want to emphasize something > extremely important to you. I use it on pet projects, and tried to use it for at work (for my own consumption) for a big C++/Qt project. I really like Qbs, but i will try to focus on the dark areas, i guess you want to hear these as well. IMHO, the main show stopper for Qbs adoption is lack of support in the most popular IDEs. Visual Studio, Visual Code, XCode, Eclipse, ... are not Qbs aware. The minimum needed would be that these tools at least understand how to read it (to get list of source, targets, ...), and how to fire build, clean, run steps. At work, most of the devs use Visual Studio, and there are on-going discussions about switching to CMake, if only VS could handle Qbs... I think Qbs is a great tool, I like the language and the modern design. However, what i don't like: - Too "elitist": cannot easily be used on projects with dodgy dependencies, it seem to offer an all or nothing. - toolchain and Qt profiles, are IMHO counter-intuitive. Qbs is the only build tool i'm aware of that requires having "global" profiles. IMHO profiles should be managed at "configure time" of a project, gcc and Qt profiles should be managed via probes? - Command line interface could be simplified and be more end-user friendly, as of now it still looks like a power-user tool I've always like the GNU autotools workflow (but not the underlying technology!), eg I should be able to do: $ qbs configure --enable-foo --disable-bar --with-stuff=/usr/local/... $ qbs build $ qbs check $ qbs install DESTDIR=... $ qbs package The above functionalities can be done with qbs, but i think that it should be as simple as the above commands, something straight forward. Last thing, Qbs has built-in support for different compilers/linkers, this is nice b/c I can just express my toolchian flags in a toolchain agnostic way, but... - Qbs will have to continuously catch up with the fast moving toolchain world - Users depend on Qbs core team to gain support for exotic compilers - You will never be able to unify them all, too much specificities, corner cases, ... - Other tools have different approaches, they let users have their own boiler plate inside their projects. It is a strength of Qbs, but somehow it could be a weakness at the same time. Keep up the good job! Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] qbs project file parser
On 28 May 2018 at 07:09, sanjay chopra wrote: > Hi, > > I am thinking of writing a plugin for qtcreator which shows assembly > output of ource at the time of editing(like godbolt.org), I am using qbs > as build system. Qbs can have different build setting(compiler flags) for > each source file, is there any library for parsing qbs file and read > settings (compiler flags) for a source file in project ? > If it's for a QtC plugin, you shouldn't be Qbs specific then.Surely QtC offers you all the information you need. Chris > > *RegardsSanjay* > > ___ > 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] qbs project file parser
On 28 May 2018 at 07:09, sanjay chopra wrote: > Hi, > > I am thinking of writing a plugin for qtcreator which shows assembly > output of ource at the time of editing(like godbolt.org), I am using qbs > as build system. Qbs can have different build setting(compiler flags) for > each source file, is there any library for parsing qbs file and read > settings (compiler flags) for a source file in project ? > You should maybe ask this question on QtCreator mailing list, if it's a QtC plugin, you shouldn't be Qbs specific. Surely QtC offers you all the information you need. Now showing the assembler for an isolated, small piece of code is way easier than "on the fly" in a C++ project. Any way interesting. > > *RegardsSanjay* > > ___ > 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] GCC: --start-group vs --whole-archive
On 24 May 2018 at 20:39, Christian Kandeler wrote:
> On Thu, 24 May 2018 17:12:26 +1200
> Christian Gagneraud wrote:
>
>> I'm trying to link internal static libraries to an application, Qbs
>> made the choice to give the linker command a list of full path to the
>> library archives.
>> Because I cannot rely on proper dependency tracking b/w all the static
>> libraries, I get link errors due to how ld works: it picks up only
>> unseen symbols as it process the list of archives, which is different
>> from what msvc does: take all the static libs in a global pool and
>> make sure nothing is missing.
>>
>> My list of dependencies is "complete", but libs might have cyclic deps
>> (!) and i cannot sort out what is the proper link ordering.
>
> Why do they have cyclic dependencies? Did you design them this way?
They grew up like this, i guess because VisualStudio+msvc doesn't care
about this sort of things.
I know that this is bad, please don't start telling me that, you would
be preaching a converted.
This won't be addressed any time soon, first of all b/c this is not a
problem, as long as the set of required static libraries is given to
VisualStudio+msvc or qmake+gcc so that an application can be linked.
Actaually nobody really knows if there are cyclic dependencies or not
(just heavy suspicion. Eg, bfd linker running out of memory on
machines that have 0.25TB of RAM) since they are considered as "a bag
of dependencies", without individual inter-depedency tracking.
Again, qmake can cope with that, and actually cmake can too (we use to
have a proof of concept, but is not maintained). So why not Qbs?
>> Both VisualStudio+msvc and QMake+gcc can deal with that.
>
> And qbs + msvc, I would assume?
I do not know, for now i'm just trying to get it working on x86-linux.
But i highly suspect that this statement is correct.
It all boil downs to GNU linker vs MSVC linker.
GNU picks up symbols as needed and discard the rest, for each library,
in given order, MSVC fills up a global symbol table from all
dependencies and then picks what it needs.
>> I have tried to use the linkWholeArchive this way:
>> Application {
>> name: "Foo"
>> Depends { name: "cpp" }
>> cpp.linkerFlags: ["-fuse-ld=gold"] // bfd runs out of memory
>> files: [ ... ]
>> Depends { name: "Qt" ... }
>> Depends { name: "Bar"; cpp.linkWholeArchive: true }
>> Depends { name: "Baz"; cpp.linkWholeArchive: true }
>> // And more ...
>> }
>>
>> My static library only declare dependencies on Qt, and they don't use
>> any "Export".
>>
>> Qbs generate a command-line using "-Wl,--whole-archive
>> /path/to/libBar.a /path/to/libBaz.a --no-whole-archive", but the
>> linker failed with weird messages about both missing symbols and
>> duplicated symbols.
>
> What kind of symbols are these?
I don't have the list right here, but i can tell you that it looked
really weird!
And again the list of static library is correct (msvc, qmake, cmake
can cope with that), and the order in which they appear in the qbs
file is the same as in the pro file or the vcxproj file.
I do agree that this is a degenerated use-case, but i'm not the first
one to ask for that.
The cpp.linkWholeArchive feature came from a user request for a very
similar scenario.
>> If I copy the generated command in the terminal and replace
>> --whole-archive with --start-group, and --no-whole-archive with
>> --end-group, then the link succeed (and is way faster). AFAIU, this
>> allows GNU ld to behave like msvc.
>>
>> Another way to get the linkage working is to replace all the
>> /path/to/libXYZ.a with -L /path/to -l XYZ. This is what qmake is
>> doing, and again it works well (same codebase). I know that doing that
>> can cause problems if the linker has the choice of shared and archived
>> libs, but in my case, "it just works" b/c we only build static
>> libraries.
>
> In which version of your command line did you do that change? The one with
> --whole-archive?
Yes, just copy/paste the command line generated by Qbs, replace
--whole-archive with --start-group and --no-whole-archive with
--end-group.
As all my in-project static dependencies all use
"cpp.linkWholeArchive: true" Qbs grouped them and generate a single
--whole-archive and a single --no-whole-archive, in the middle of them
are all my /path/to/libFoo|Bar|Baz.a
>
>> Is there a chance i can tweak qbs so that my scenario works?
>
> If you really have cyclic dependencies between your libraries, then obviously
> that defeats the whole dependency management approach. In such a cas
[Qbs] GCC: --start-group vs --whole-archive
Hi there,
I'm trying to link internal static libraries to an application, Qbs
made the choice to give the linker command a list of full path to the
library archives.
Because I cannot rely on proper dependency tracking b/w all the static
libraries, I get link errors due to how ld works: it picks up only
unseen symbols as it process the list of archives, which is different
from what msvc does: take all the static libs in a global pool and
make sure nothing is missing.
My list of dependencies is "complete", but libs might have cyclic deps
(!) and i cannot sort out what is the proper link ordering. Both
VisualStudio+msvc and QMake+gcc can deal with that.
I have tried to use the linkWholeArchive this way:
Application {
name: "Foo"
Depends { name: "cpp" }
cpp.linkerFlags: ["-fuse-ld=gold"] // bfd runs out of memory
files: [ ... ]
Depends { name: "Qt" ... }
Depends { name: "Bar"; cpp.linkWholeArchive: true }
Depends { name: "Baz"; cpp.linkWholeArchive: true }
// And more ...
}
My static library only declare dependencies on Qt, and they don't use
any "Export".
Qbs generate a command-line using "-Wl,--whole-archive
/path/to/libBar.a /path/to/libBaz.a --no-whole-archive", but the
linker failed with weird messages about both missing symbols and
duplicated symbols.
W/o cpp.linkWholeArchive I get tons of undefined symbols, and I cannot
take the risk to use allowUnresolvedSymbols.
If I copy the generated command in the terminal and replace
--whole-archive with --start-group, and --no-whole-archive with
--end-group, then the link succeed (and is way faster). AFAIU, this
allows GNU ld to behave like msvc.
Another way to get the linkage working is to replace all the
/path/to/libXYZ.a with -L /path/to -l XYZ. This is what qmake is
doing, and again it works well (same codebase). I know that doing that
can cause problems if the linker has the choice of shared and archived
libs, but in my case, "it just works" b/c we only build static
libraries.
Is there a chance i can tweak qbs so that my scenario works?
I'm using custom build of QtCreator-4.6+Qbs-1.11.1, custom build of
Qt-5.6 and distro gcc-5.3, i386/Ubuntu-16.04 docker container on
amd64/Ubuntu-16.04 host.
Thanks,
Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] cpp.cppFlags and ccache
Hi, I was building my qbs project with QtCreator, my products use 'cpp.cppFlags: [ "-Wno-unknown-pragmas" ]', when i use a kit that use /usr/bin/g++, everything work as expected (no gcc warning about '#pragma warning', when i switch to /usr/lib/ccache/g++ (a symlink to /.usr/bin/ccache), i get tons of gcc about '#pragma warning'. The command line generated by qbs is: /usr/lib/ccache/g++ ... -Wp,-Wno-unknown-pragmas ... I don't know why this is prefixed with -Wp, but it seems to annoy ccache. >From gcc doc: You can use -Wp,option to bypass the compiler driver and pass option directly through to the preprocessor. If option contains commas, it is split into multiple options at the commas. However, many options are modified, translated or interpreted by the compiler driver before being passed to the preprocessor, and -Wp forcibly bypasses this phase. The preprocessor's direct interface is undocumented and subject to change, so whenever possible you should avoid using -Wp and let the driver handle the options instead. Could it be a bug with ccache, or is Qbs doing something wrong/weird? Looking at changelog of ccache, it seems that quite a few things have been fixed regarding -Wp, but most of them deal with -Wp,-M/P/D. ccache 3.2.4, gcc 5.4.0, i386/ubuntu-16.04 Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] qbs, qmake and filename case sensitivity
On 21 May 2018 at 18:57, NIkolai Marchenko wrote: > Sadly, I think the way Qbs does it is correct. Why 'sadly', i wasn't complaining, just reporting my findings, and looking for other's opinion. > These subtle naming errors are better found early before they mess up > something when you try to use the project outside the "helpful" build system > as you have just found out. > It's better to fix these early than frantically search for problems when > time is critical. Agree, convenience tends to bring un-repeatable 'magic'. Strictness brings repeatability, but is usually verbose/noisy. Something else I've just discovered about qmake, is that you can 'forget' which Qt module you depend on. Qmake seems to scan your source file and add missing Qt dependencies automagically! How can you trust a tool that do stuff "on your back"... Chris > > On Mon, May 21, 2018 at 1:56 AM, Christian Gagneraud > wrote: >> >> Hi there, >> >> In a mixed Linux/Windows environment, qmake seems to deal with >> filename case sensitivity automagically. >> I have a '.pro' file that contains say FOOBar.ccp, but on disk - on >> Linux, FOOBar.cpp doesn't exists and FooBar.cpp does. >> QMake magically generates a Makefile file with FooBar.cpp instead of >> FOOBar.cpp, and the build passes. >> >> This '.pro' file is automatically generated from Visual Studio >> solution and project files using in-house python scripts, which means >> that the 'error' is inside vcxproj files but as Windows doesn't care >> about case sensistivity, it is not a problem - on Windows. >> >> Using this system of python scripts, i'm now generating 'qbs' files, >> the Qbs file contains 'FOOBar.cpp, and this time Qbs - on Linux - >> complains (rightly) that FOOBar.cpp doesn't exist. >> >> I am not sure what is the best behaviour: >> - QMake being convenient. >> - Qbs being strict. >> >> Should Qbs mimic what qmake does? >> >> Chris >> ___ >> 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] qbs, qmake and filename case sensitivity
Hi there, In a mixed Linux/Windows environment, qmake seems to deal with filename case sensitivity automagically. I have a '.pro' file that contains say FOOBar.ccp, but on disk - on Linux, FOOBar.cpp doesn't exists and FooBar.cpp does. QMake magically generates a Makefile file with FooBar.cpp instead of FOOBar.cpp, and the build passes. This '.pro' file is automatically generated from Visual Studio solution and project files using in-house python scripts, which means that the 'error' is inside vcxproj files but as Windows doesn't care about case sensistivity, it is not a problem - on Windows. Using this system of python scripts, i'm now generating 'qbs' files, the Qbs file contains 'FOOBar.cpp, and this time Qbs - on Linux - complains (rightly) that FOOBar.cpp doesn't exist. I am not sure what is the best behaviour: - QMake being convenient. - Qbs being strict. Should Qbs mimic what qmake does? Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )
On 16 January 2018 at 17:00, Wookey wrote: > On 2018-01-16 12:08 +1300, Christian Gagneraud wrote: >> >> I found this piece of information very interesting indeed, what's your >> stance about -march then? In my case, I have one toolchain per platform >> (roughly), they all have the same generic triplet (arm-linux-gnueabi), but >> target different ARM arch (armv5te, armv6, cortex A?, ...) and actually have >> sometimes different float ABI. > > I think you are doing it wrong, in more than one way :-) Easy answer: "they" are doing it wrong (the other team), and as a consumer of their work i'm just trying to bring some consistency, hence all my questions/comments. > I like to distinguish between ISA (instruction set) and ABI > (Application Binary Interface). An 'architecture' in Debian is > actually an ABI (not a machine, nor a CPU). That never changes for the > lifetime of the architecture. The ISA that arch is built with can > change over time as newer hardware becomes a sensible default i386-> > i486 -> i686 in the i386-linux-gnu ABI, and armv4t -> armv5 -> armv7 > in the arm-linux-gnueabi ABI, for example. My personal (p)references in term of ISA stability would be sparc and ppc, but at work i have to deal with x86 32/64 and arm v5/6/7/8... On top of that are desktop and custom embedded GNU/Linux, Android/Linux, with a mix of gcc and clang as a final topping choice. Not talking about sse, avx, neon, vfp, Qt's own qreal=float or double, arm vs x86 char signed-ness, ... I think that "how do you name a toolchain" is a legit question and the old GNU triplet/quadruplet myth is, well, just a myth! ;) I remember vaguely the "gnueabi" vs "oldabi" vs "" toolchain mess when the hard-float call convention was introduced into the arm-linux kernel ... > Does that all make sense. Are we off-topic for this mailing list yet? Yes it does, and Qbs aims to be OS/toolchain agnostic, so I don't think this is fully off-topic. IMHO, all these questions/answers fully makes sense on this ML. Enlightenment and sanity are always welcome! ;) Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )
On 16/01/2018 4:23 AM, Wookey wrote: On 2018-01-15 15:13 +0100, Ola Røer Thorsen wrote: I've got a product running on Linux arm imx6. It's being cross-compiled on Linux x86_64. I've got it set up with both qmake and now qbs that hopefully should replace qmake at some point. The qmake build ends up linking the application with a command line like this: arm-fslc-linux-gnueabi-g++ -mfloat-abi=hard I'm struggling to find the property or similar in the cpp module that adds the "-mfloat-abi=hard"-option to g++ when used for linking. It's not just linking, its an ABI option that applies to the compile stage too. ABIs are so fundamental that these are two different architectures in Debian-based distros: armel and armhf. Which have different toolchains, and cross-toolchains, so if you use the right triplet then you get the right output and everything matches up. I would question why you are using a linux-gnueabi toolchain when you want linux-gnueabihf outputs. Obviously it can be done, but a good way to avoid problems with the wrong ABI is to use a toolchain that defaults to the right thing. I don't know what your base distro is, but if it's debian-based then using a the distro-supplied arm-linux-gnueabihf-g++ would avoid this problem completely. If you are in redhat-world I presume there are equivalent cross-toolchains. Keeping ABI info in triplets is much cleaner than special-casing the magic option for getting one ABI whilst building with a toolchain for another, especially in upstream projects. (this includes -m32/-m64 in x86 world, which is also a special case that doesn't necessarily work on other architectures and architecture-pairs). I reaslise this is a rather tangential answer to your actual question, but it is hopefully helpful. I found this piece of information very interesting indeed, what's your stance about -march then? In my case, I have one toolchain per platform (roughly), they all have the same generic triplet (arm-linux-gnueabi), but target different ARM arch (armv5te, armv6, cortex A?, ...) and actually have sometimes different float ABI. I'm currently trying to refactor that to have more consistency across our toolchains, so your above comments caught my attention. Chris PS: Glad to see you on this ML, I remember you from the Emdebian project when I gave it a try, that was 10 years ago! ;) Wookey ___ 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] Qbs system settings
On 15/12/2017 10:26 pm, "Christian Kandeler" wrote: On Wed, 13 Dec 2017 18:10:42 +1300 Christian Gagneraud wrote: > I would like to setup qbs profile system wide, I have tried using the > '--settings-dir' (eg qbs-setup-qt --settings-dir /etc/xdg), but then > qbs-config doesn't seem to read the system settings. > > $ /opt/qt/5.6/bin/qtpaths --paths GenericConfigLocation > /root/.config:/etc/xdg > $ /opt/qt/5.6/bin/qtpaths --paths ConfigLocation > /root/.config:/etc/xdg > > I would expect that qbs-config would see profiles defined system-wise > too. But it seems that i need to use qbs-config --settings-dir > > Can Qbs pick up build profiles defined system-wide? Looking at the source code, the answer seems to be "not reliably". We use QSettings internally, which can look up the system default, but if you give the --settings-dir option, we use a QSettings constructor which doesn't do that. So system-global settings are not really supported at the moment. You might want to file a bug report for that. Thanks for that. I'll raise a ticket as I think it's a basic but important feature. Chris 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] QT_DEBUG defined on release builds
On 17/12/2017 2:21 am, "NIkolai Marchenko" wrote:
cpp.defines: base.concat(['SOMETHING', 'SOMETHING_ELSE'])
Could someone explain the rules as to when to use base.concat or not, eg is
it necessary here just because of the group? Or should this be always used?
(Project, Product, Module, ...)
The problem is that you don't get warning when you overwrite an array
property, so it's easy to loose information and potentially difficult to
trace.
Chris.
On Sat, Dec 16, 2017 at 4:14 PM, Ely wrote:
> I have a project roughly specified like this:
>
> > Project {
> > CppApplication {
> > Depends { name: "Qt.core" ... }
> > Group {
> > file: ['main.cpp']
> > cpp.defines: ['SOMETHING', 'SOMETHING_ELSE']
> > }
> >}
> > }
>
> With this setup, I get the following defines on a release build:
> > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE
>
> But when the cpp.defines are not placed in a group, I get these:
> > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE -DQT_CORE_LIB -DQT_NO_DEBUG
>
> This is a problem, because without QT_NO_DEBUG, all code in checking for
> QT_DEBUG compiles.
>
> I'm using qbs 1.10.
> ___
> 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 mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Qbs system settings
Hi there, I would like to setup qbs profile system wide, I have tried using the '--settings-dir' (eg qbs-setup-qt --settings-dir /etc/xdg), but then qbs-config doesn't seem to read the system settings. $ /opt/qt/5.6/bin/qtpaths --paths GenericConfigLocation /root/.config:/etc/xdg $ /opt/qt/5.6/bin/qtpaths --paths ConfigLocation /root/.config:/etc/xdg I would expect that qbs-config would see profiles defined system-wise too. But it seems that i need to use qbs-config --settings-dir Can Qbs pick up build profiles defined system-wide? I have try as well with --settings-dir /etc/xdg/QtProject, but it doesn't make any difference Thanks, Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Qtc+Qbs+git wroktree = cannot lock build graph
Hi there, Not sure if it's a Qtc or a Qbs issue, but here is my problem: I'm using git worktrees, which means i have the same project checked-out on different branches in different sibling directories, the main qbs files have the same name, and so by default, Qtc try to use the same build directory, luckily qbs refuse to go ahead (not sure if with qmake i'll get a warning about that). Anyway, the solution is to edit the project's build settings. It's OK, but it's a bit annoying over time. What about if Qtc would hash the path to the project file and use it (as a prefix) to name the default build folder? Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Dependencies on internal products using 'submodules'
On 03/12/17 20:40, Jake Petroules wrote:
Qbs has a global view of the entire project, so there's no need to
qualify the names of your lib1, lib2 dependencies with the name of
the sub-project in which they're defined. I think your idea of a
cleaner syntax could be something of the form:
Depends { names: ["lib1", "lib2"] }
Basically, a condensed syntax that would allow to specify multiple
dependency names in a single depends item, and optionally apply
additional properties to all of those, like so:
Depends { names: ["lib1", "lib2"]; condition: project.hasCoolLibs }
equivalent to:
Depends { name: "lib1"; condition: project.hasCoolLibs } Depends {
name: "lib2"; condition: project.hasCoolLibs }
A "names" property as such would be mutually exclusive with the
existing submodules and productTypes property, as well as the name
property.
However your proposal as-is cannot work as the name of a dependency
must be the name of a product or module, and projects have nothing to
do with this. I don't think trying to add them into the mix would
make any sense, but I think something what I suggested above would
effectively solve the same problem I believe you're looking to do so,
which is to remove redundant syntax (and my proposal requires fewer
characters too :D).
Hi Jakes,
Yes, I sort of knew that project/products have nothing to do with
modules (I don't know why, but i've read something about it).
I like your proposition, it's IMHO a good compromise.
On the other hand you say that "there is no need to qualify a dependency
with the name of the project where it is declared", and it seems to
justify why this is not supported. "Not necessary" doesn't always imply
"not possible". After all there's already similar mechanism with
limitToSubProject (Depends/Project coupling), so why not allowing an
optional syntax, where name refers to a project, and submodules refer to
products from this project. Or maybe in that case, a "project" property
could be use in place of "name" (that would make the Depends item syntax
a bit messy tho). One (wild mind ;)) could imagine something like:
Depends {
project: "MyLibraries"
products: [
"lib1",
...
]
}
I don't know the internals of Qbs, so please excuse me if the above
doesn't make sense to you.
This is not a show stopper for me, just a nice to have. IMHO it keeps
the product.qbs tidy, and is in sync with the concept that you write
code once, but it gets read countless time, so it's good to make it easy
to read/understand.
Is it worth creating a proposal/use-case ticket based on this thread?
Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Dependencies on internal products using 'submodules'
Hi there,
I would like to know if it's possible to list internal product
dependencies using the 'submodules' syntax, eg:
MyProduct {
name: "foo"
files: [
...
]
Depends {
name: "Qt"
submodules: [
...
]
}
Depends {
name: "LibrarySubProject"
submodules: [ // <=
"lib1",
"lib2"
]
}
}
Where "LibrarySubProject" is an inline sub-project in the root project
and lib1, lib2 are internal library products referenced by "SubProject".
This is different from my "third party" modules defined in
$qbsSearchPath/modules/ThirdParty/..."
I know I can use the Depends { name: "lib1" } form, but for "cosmetic"
reasons, I would like to use the 'submodules' approach.
You might think that i'm a bit picky, but using this syntax, it makes
the product.qbs easy to read, pleasant *and* easy to understand.
That could help me to convince people while show-casing qbs.
I could write one module per library in $qbsSearchPath/modules/ but that
would be redundant and a bit awkward to maintain.
Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qt doc, qtmain and qbs
On 28/11/2017 12:16 PM, Jake Petroules wrote: Shouldn't qbs be in the build tools list too, eg: "If you do not use qmake, qbs or other build tools such as CMake" Is it worth creating a Qt ticket (and a change request)? Is so, are you happy with the above phrasing? Yes, and yes. For the first yes: https://bugreports.qt.io/browse/QTBUG-64803 Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Qt doc, qtmain and qbs
Hi there, I was looking at the usage of the qtmain static library (on Windows), i wasn't aware of this, so i looked up the Qt documentation and it says: qtmain is a helper library that enables the developer to write a cross-platform main() function on Windows. If you do not use qmake or other build tools such as CMake, then you need to link against the qtmain library. Shouldn't qbs be in the build tools list too, eg: "If you do not use qmake, qbs or other build tools such as CMake" Is it worth creating a Qt ticket (and a change request)? Is so, are you happy with the above phrasing? Chris PS: Congrats for the new online Qbs documentation! ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and ccache (and QtC)
On 23/11/2017 10:52 PM, Christian Kandeler wrote: On Thu, 23 Nov 2017 15:34:14 +1300 Christian Gagneraud wrote: I just tried to enable ccache in QtCreator, and qbs failed complaining it cannot find 'ar' and co. This should be fixed for 1.10. Earlier versions assumed the binutils to be at the same location as the compiler, so you have to manually set cpp.archiverPath there (also stripPath, objcopyPath and nmPath). Good to know, thanks. I will wait for qbs-1.10. Is this the right way to deal with ccache and QtC+Qbs? Should I open a bug report? On Qtc, Qbs or both? Please double-check with an up to date version the tools. Note that an alternative way to use ccache with qbs is to use the real gcc and set cpp.compilerWrapper to ccache. I think i'll use that in the mean time, I should be able to set that in the "Additional Qbs Profile Settings" of a kit. Thanks a lot, Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Tighter clang tooling integration
On 22/11/2017 11:17 PM, Christian Kandeler wrote: On Wed, 22 Nov 2017 17:42:23 +1300 Christian Gagneraud wrote: I could maybe use a custom Rule item, one that "transform" every .cpp file into, say a .clazy file (output of clazy on the .cpp file). The interesting question here is how to get at the fully expanded command lines without code duplication. This code is in the compiler rules of the cpp module; that's why it appears that there needs to be some tight integration with that module. The clang db plugin can do exactly that [1], so what about: jobqueue.start() for each project for each product for each group for each source command= userCommand(project.ruleCommands(product, source)) jobqueue.append(makeJob(command)) jobqueue.wait() ... Or something along these lines, i am not familiar with Qbs internals. However, clazy for example is really just a compiler, so you can use it already today by simply setting cpp.compilerName to "clazy". OK, clazy might not be the best example, let's consider clang-check or clang-tidy then or any other (custom) clang-based tool not designed to be run this way. Chris [1] https://github.com/qbs/qbs/blob/master/src/plugins/generator/clangcompilationdb/clangcompilationdbgenerator.cpp#L70 ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Qbs and ccache (and QtC)
Hi there, QtC-4.5.0-rc1, qbs-1.10.0. I just tried to enable ccache in QtCreator, and qbs failed complaining it cannot find 'ar' and co. When i want to enable ccache, i use the export PATH=/usr/lib/ccache:$PATH trick (which is IMHO the "proper" way to deal with this on Linux). When i run QtC within this env, I can see new C/C++ compilers, eg. "GCC (C++, x86 32bit in /usr/lib/ccache)" along "GCC (C++, x86 32bit in /usr/bin)" - actually i'm not sure if they are auto-detected or if i set that up myself some time ago. I then clone my Qt profile, change the C/C++ compilers to use the ccache'd ones), and then simply rename the profile to "Qt X.Y (ccache)" When I select this Qt ccache'd profile, qbs complains that /usr/lib/ccache/ar doesn't exists. The problem seems to stem from Qbs trying to infer the path to 'ar' based on the path to gcc. Is this the right way to deal with ccache and QtC+Qbs? Should I open a bug report? On Qtc, Qbs or both? Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Question about linking (linux-gcc)
Hi there, I have two questions related to the linking process, I'm using qbs-1.10 (as per QtC) on a Ubuntu 17.04 x86_32 VM. First the simple one: What is the best way to choose which binutils linker to use? I would like to activate the gold linker instead of the bfd one (default), gcc option for this is "-fuse-ld=gold", I think this option *has* to be passed to gcc, so i wonder if cpp.linkerFlags is the correct place, I know it works, but i'm curious to know if there's a better way to do it. My 2nd question requires a bit of explanation first: I need to link an app against lots of static libraries. Each static library has a list of Depends (mostly Qt deps). Qbs generate a link command for my app by simply appending all the libs' depends. So I endup with a very-very long command line that contains hundreds of duplicated Qt linking fragments. The actual link command is 49384 character longs! For some reason, it upset the linker (like the linker doesn't seem to simplify the command line), I have currently 4 link processes that have been running for more than half an hour, with qmake the link time is a couple of minutes with bfd, with qmake and the gold linker, the link time is roughly a minute or less (2.5 increase in speed). My static libraries qbs files are very-very simple, a file list, a Depends for Qt. I do not use (anymore) exported depends. Is it possible to work this around? I have the feeling that it might be due to the use of lto, as the g++ sub-process starts with: /usr/bin/ld -plugin .../liblto_plugin.co When I use the gold linker (with qbs) I do not have this problem, even tho the subprocess starts with /usr/bin/ld.gold -plugin .../liblto_plugin.co Any idea about that, is it a qbs issue or should I blame it on the bfd linker? Thanks, Chris PS: I am actually interested in evaluating LTO, but that's something that will come later (LTO is an expansive operation) ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Licensing of my own QBS modules
On 22/11/2017 12:10 AM, Карелин Павел wrote: Hi, guys! I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? Can I use a MIT license? Hi Pavel, Could you provide a link to your repo(s), this looks quite interesting. Chris -- BR, Pavel Karelin ___ 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] Tighter clang tooling integration
On 21/11/2017 10:46 PM, Christian Kandeler wrote:
On Tue, 21 Nov 2017 18:01:32 +1300 Christian Gagneraud
wrote:
Qbs can generate a clang compilation database. Some (most)
clang-based tools are not multi-cpu aware.
For example a typical use of clang-check is cd repo.git qbs
generate -g clangdb profile:someprofile # or cmake
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON find path/to/some/code -name
'*.cpp' | xargs clang-check -analyze -p=someprofile
As a side note, in my case CMake generate one database per "module"
(lib, app, ...), whereas qbs generate a single database for the whole
project. I do prefer the single database right now, but the one database
per Qbs product could be interested too.
The plugin could be improved by adding an optional product name on the
command line.
There are a few annoying things with this: - First you need to give
clang-check which file you want to check - clang-check will process
all the files one after another, even if you have multi CPU
This one you can probably work around, e.g. using GNU parallel.
Thanks for the tips! I wasn't aware of this one, maybe that's all I need
(i'm looking for a simple solution).
- find path/to/some/code -name '*.cpp' might retun files that
should not be compiled.
Wouldn't it be nice if we could ask qbs to run a clang-based tools
on all the source files and with proper load distribution?
Is this something that looks doable? Is it even wanted?
This has come up before. It looked deceptively tempting at first to
just set the compiler to the clang tool and then "build" as normal,
but upon closer inspection, there were some issues. The most obvious
one would be that you'd have to somehow stop after the "compile"
step, but there were others as well (I forgot the details). If you
Agree, it doesn't seems like the right approach even if sounds "easy" at
first.
play around a bit in that area (perhaps with a dedicated module?),
you'll probably get more insight into where the problems lie.
I could maybe use a custom Rule item, one that "transform" every .cpp
file into, say a .clazy file (output of clazy on the .cpp file).
But then i would have to tell qbs that i want a "master" file that
depends on all the individual '.clazy' files.
This still looks like a hack.
Can't stop thinking of a 'qbs for-each-cpp somecommand --someflag {}'
(similar to the 'find' and 'git for-each' commands)
Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] Tighter clang tooling integration
Hi, Qbs can generate a clang compilation database. Some (most) clang-based tools are not multi-cpu aware. For example a typical use of clang-check is cd repo.git qbs generate -g clangdb profile:someprofile # or cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON find path/to/some/code -name '*.cpp' | xargs clang-check -analyze -p=someprofile There are a few annoying things with this: - First you need to give clang-check which file you want to check - clang-check will process all the files one after another, even if you have multi CPU - find path/to/some/code -name '*.cpp' might retun files that should not be compiled. Wouldn't it be nice if we could ask qbs to run a clang-based tools on all the source files and with proper load distribution? Is this something that looks doable? Is it even wanted? Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Layout of qbs cpp documentation
On 3/11/2017 10:10 PM, Oswald Buddenhagen wrote: On Fri, Nov 03, 2017 at 10:03:35AM +0100, Timur Kristóf wrote: I've recently visited the docs at http://doc.qt.io/qbs/cpp-module.html It looks like this: https://imgur.com/a/SwIm6 Is this the intended look-and-feel of the docs? https://bugreports.qt.io/browse/QBS-1195 Could we change the current layout of the qbs docs to match that of the qml docs? i suppose that would be an option. Another option would be to fix the HTML/CSS used for tables. Any table on doc.qt.io suffer from this (very) annoying bug. My 2 cents, Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Passing unescaped flags to the linker
On 2 November 2017 at 23:50, Timur Kristóf wrote: > Hi, > >> I use the latest versions (Qt Creator 4.4.1 and QBS 1.9.1) available on >> Windows. >> I just configured a Kit with my ARM toolchain, created a minimal qbs >> project that compile >> and run the static analyzer. > > What I did was to set up scan-build as a compiler wrapper in my qbs file, so > arm-none-eabi-g++ ... > becomes > scan-build arm-none-eabi-g++ ... > And it didn't complain for any of those flags. But this was months > ago, and I couldn't exactly figure out how to make it work (due to > qbs-unrelated issues), so maybe the latest version of the static > analyzer works differently now. > >> If I managed to make the Build step works, I haven't managed to make >> the static analyzer work completely. >> My first issue is that clang ignores the system includes in the >> sysroot (every libc or STL include fails), >> so I had to add those folders with cpp.includePaths (also I haven't >> found a way to add those only when >> running the static analyzer: putting a condition on the compiler does >> not work as gcc is still considered to be the compiler >> even if it is clang that does the static analysis). My current issue >> is that clang fails each time >> it meets a bit of assembly code in a c/c++ file, likely because it >> does not use the ARM assembler. > > After my initial experiments, I thought there must be someone who made > it work, so I posted a StackOverflow question. > It is still unsolved, but maybe it is of some help to you: > https://stackoverflow.com/questions/44204695/how-to-use-clang-static-analyzer-with-a-cortex-m-project > > Now we are off-topic with regards to the qbs mailing list, but I'm > very interested in your static analyzer effort, so please let me know > if you find a way to get it working! To get rid of errors/warnings in external headers, you have to use -isystem instead of -I, clang wont complain about code in system headers. In our project any "foreign" include path is added with -isystem, this includes Qt too. There's the -isysroot as well as explained on QtC mailing list. Have you tried to export the clang compilation database with Qbs and then use it with your clang-based tool? Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] build graph and dependency visualisation
On 1/11/2017 11:02 PM, Christian Kandeler wrote: On Tue, 31 Oct 2017 12:42:33 +1300 Christian Gagneraud wrote: Is it possible to dump the build graph (eg for graphviz), There is the dump-nodes-tree command, which gives you a textual representation. You won't have much fun looking at a graphical representation of any non-trivial project. and the build dependencies. If not, are there any plan? No and no. Though I suppose the list-products command could be extended to cover that, if there is a use case. I should have been more precise, I'm interested in product inter-dependencies, not build/source files dependencies, I think the graph will still be a bit messy, but there are tool to massage and visualise dot files, it's all about giving the right hints. I will have a look at dump-nodes-tree and list-products. Thanks, Chris 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
