[QBS] Qt 4.8.6 mingw482. Qt-profiles can't be created (bugreport QBS-629).

2014-06-22 Thread Карелин Павел

Hello,

I installed qt-opensource-windows-x86-mingw482-4.8.6-1.exe. Next step - 
cloning QBS from git-repository. Then build QBS (branch 1.2); 
configuring QBS-profiles. When run qbs-setup-qt.exe --detect I receive a 
mistake: mkspec '${MINGW482_INSTDIR}/mkspecs/win32-g++-4.6' does not exist




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


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

2014-10-19 Thread Карелин Павел

Hi,
Some time ago such theme was discussed in mailing for Qt-creator
As I understand, building of QtCreator on Qt4 still remains, because Qt 
5.x have problems with font rendering. 
(https://bugreports.qt-project.org/browse/QTBUG-37749)

If your drop support for building qbs with Qt4 - how build QtCreator on Qt4?

--
Pavel Karelin


17.10.2014 13:51, Joerg Bornemann пишет:

Hi,

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

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


Cheers,

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


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


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

2014-10-19 Thread Карелин Павел


20.10.2014 00:00, Orgad Shaneh пишет:


Qt Creator requires Qt 5.3 starting from 3.3.

I do not mind Qt5, only problem with fonts I would like to see is 
fixed.  Eyes do not last  forever ...




- Orgad

בתאריך 19 באוק 2014 22:58, Карелин Павел hka...@yandex.ru 
mailto:hka...@yandex.ru כתב:


Hi,
Some time ago such theme was discussed in mailing for Qt-creator
As I understand, building of QtCreator on Qt4 still remains,
because Qt 5.x have problems with font rendering.
(https://bugreports.qt-project.org/browse/QTBUG-37749)
If your drop support for building qbs with Qt4 - how build
QtCreator on Qt4?

--
Pavel Karelin


17.10.2014 13:51, Joerg Bornemann пишет:

Hi,

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

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


Cheers,

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



___
QBS mailing list
QBS@qt-project.org mailto: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] Directive import qbs. Whether it is necessary to define a version?

2015-05-16 Thread Карелин Павел

Hi, guis!

Almost always qbs-scripts is beginning from a directive import qbs. In 
some scripts, the version is assigned (import qbs 1.0), but in others 
- is no (import qbs).

In what cases, is need to specify the version?

--
Best regards,
Pavel Karelin.
___
QBS mailing list
QBS@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs


Re: [QBS] module for KDSoap

2016-09-20 Thread Карелин Павел

Hello, Ioan.


20.09.2016 12:35, Ioan Calin Borcoman пишет:

Adding to both the module and the project using it:

   Depends { name: "Qt"; submodules: ["core", "network"]}

didn't solve the problem, unfortunately.

I have reported this as https://bugreports.qt.io/browse/QBS-1021.

Regarding your suggestion b), how can I do it? I haven't seen any qbs
examples returning multiple executables for the same rule. Also, from
what I understand, the "wsdl_foo.h" should be tagged as "hpp", while
the "wsdl_foo.cpp" as "cpp". Is my understanding correct? Can I do
this using a single rule? How?
I also had a similar problem on generation the soap- cpp/h files. I 
managed to solve this problem.
I have attached an example of his QBS-module. Perhaps he will prompt you 
how to solve the problem.


Thank you,

Ioan

On Tue, Sep 20, 2016 at 3:51 AM, Christian Kandeler
 wrote:

Ioan Calin Borcoman  wrote:


I'm trying to write a module that generates wsdl_foo.h and
wsdl_foo.cpp from foo.wsdl, using KDSoap's kdwsdl2cpp
(https://github.com/KDAB/KDSoap).

After it is generated, the wsdl_foo.h should be parsed by moc, as it
contains an QObject based class.
The problem is that moc is sometimes called and sometimes isn't. If I
delete the build tree and try to run qbs from scratch, the moc is not
run and the build fails.

But if I touch my kdsoap.qbs module, even if I don't change anything
in it, and then run again qbs, the moc is run and my project builds.

Two observations:
a) Your module does not have a Qt dependency. Does your product have one?
b) (Probably unrelated to your problem) It is confusing (though not technically 
wrong) that you declare two rules. You should have only one rule that creates 
two commands.

If your answer to a) is "yes", then please file a bug at bugreports.qt.io and 
attach a complete (i.e. including source files), but minimal project.


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


--
Best regards,
Pavel Karelin.

import qbs
import qbs.File
import qbs.TextFile
import qbs.ModUtils


Module {
id: gsoap
condition: true

Depends { name: "cpp" }

property string namespace: undefined
property string modulePath: ""
property string importPath: ""
property string soapcpp2: ""
property bool   debug: false

property string generatedFilesDir: {
return product.buildDirectory + "/." + (namespace === undefined ? "soap" : namespace);
}

property string includePaths: {
return generatedFilesDir;
}

PropertyOptions {
name: "namespace"
description: "Определяет имя пространства имен для функций soap-движка."
}
PropertyOptions {
name: "modulePath"
description: "Директория расположения файлов stdsoap2.h, stdsoap2.cpp"
}
PropertyOptions {
name: "importPath"
description: "Директория расположения файлов импорта gsoap"
}
PropertyOptions {
name: "soapcpp2"
description: "Утилита soapcpp2"
}
PropertyOptions {
name: "debug"
description: "Сборка в режиме отладки"
}
PropertyOptions {
name: "generatedFilesDir"
description: "Директория размещения сгенерированных файлов, так же \
  в эту директорию копируются файлы stdsoap2.h, stdsoap2.cpp"
}

cpp.defines: {
var def = [
"WITH_COOKIES",
"WITH_GZIP",
"WITH_OPENSSL",
];

if (debug === true)
def.push("SOAP_DEBUG");

return def;
}

cpp.includePaths: {
return this.includePaths;
}

validate: {
var validator = new ModUtils.PropertyValidator("gsoap");
//validator.setRequiredProperty("namespace", namespace);
validator.setRequiredProperty("modulePath", modulePath);
validator.setRequiredProperty("importPath", importPath);
validator.setRequiredProperty("soapcpp2", soapcpp2);
validator.validate();

if (!File.exists(modulePath + "/stdsoap2.h"))
throw "Base soap-header file not found: " + modulePath + "/stdsoap2.h";

if (!File.exists(modulePath + "/stdsoap2.cpp"))
throw "Base soap-source file not found: " + modulePath + "/stdsoap2.cpp";
}

 //FileTagger {
 //patterns: ["*.wsdl"]
 //fileTags: ["wsdl"]
 //}

FileTagger {
patterns: "*.soap.h"
fileTags: ["soap"]
}

Rule {
inputs: ["soap"]
outputFileTags: ["cpp", "hpp"]

Re: [Qbs] How to pass a GCC parameter '--param inline-unit-growth=120'

2017-07-31 Thread Карелин Павел



31.07.2017 13:11, Christian Kandeler пишет:

On Mon, 31 Jul 2017 12:54:43 +0300
Карелин Павел <hka...@yandex.ru> wrote:


For a GCC compiler, I need to pass a parameter: --param
inline-unit-growth=120
I do this as follows
cpp.driverFlags: [
  "--param inline-unit-growth=120",
]

Why are you passing this as one string? Clearly, these are two separate 
command-line arguments:
 cpp.driverFlags: ["--param", "inline-unit-growth=120"]
Because logical - it's a uniform parameter. And I haven't guessed that 
it should be transmitted in two parts.

Thanks for the advice - it works

--
Pavel





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


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


[Qbs] How to pass a GCC parameter '--param inline-unit-growth=120'

2017-07-31 Thread Карелин Павел

Hi,

For a GCC compiler, I need to pass a parameter: --param 
inline-unit-growth=120

I do this as follows
cpp.driverFlags: [
"--param inline-unit-growth=120",
]

When I build, I get the following error message:

/usr/bin/g++ -O2 -Wall -Wextra*'--param inline-unit-growth=120'* -m64 
-pipe -fexceptions -fvisibility=default -std=c++11 -ggdb3 -Winline -Wall 
-Wextra -Wno-unused-parameter -DNDEBUG -DVERSION_PROJECT=0.9.13 
-DVERSION_PROJECT_MAJOR=0 -DVERSION_PROJECT_MINOR=9 
-DVERSION_PROJECT_PATCH=13 '-DGIT_REVISION="e3f7fd9"' 
-DQ_DATA_STREAM_VERSION=QDataStream::Qt_4_8 -DBPROTOCOL_VERSION_LOW=0 
-DBPROTOCOL_VERSION_HIGH=1 '-DUDP_SIGNATURE="27FR"' 
'-DCONFIG_DIR="27FacesRetail"' -DCPU_ONLY -DUSE_MKL -D_7ZIP_ST 
-D_7ZIP_ASM -DLZMA_COMPRESSION -DPPMD_COMPRESSION -DQT_CORE_LIB 
-DQT_NO_DEBUG -DQT_NETWORK_LIB 
-I/home/hkarel/CProjects/27FacesRetail/src/27fretaild 
-I/home/hkarel/CProjects/27FacesRetail/src 
-I/home/hkarel/CProjects/27FacesRetail/src/3rdparty 
-I/home/hkarel/CProjects/27FacesRetail/src/common 
-I/home/hkarel/CProjects/27FacesRetail/src/compression/src 
-I/usr/include/qt4 -I/usr/include/qt4/QtCore 
-I/usr/share/qt4/mkspecs/linux-g++-64 
-I/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/27Faces-Retail.qtc-Qt-486-d423b044.05dbb98f/qt.headers 
-I/usr/include/qt4/QtNetwork 
-I/home/hkarel/CProjects/27FacesRetail/src/shared 
-I/home/hkarel/CProjects/27FacesRetail/src/shared/shared 
-I/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/SharedLib.qtc-Qt-486-d423b044.72e7795c/qt.headers 
-isystem/home/hkarel/CProjects/27FacesRetail/src/27fretaild 
-isystem/home/hkarel/CProjects/27FacesRetail/src 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty 
-isystem/home/hkarel/CProjects/27FacesRetail/src/common 
-isystem/home/hkarel/CProjects/27FacesRetail/src/compression/src 
-isystem/usr/include/qt4 -isystem/usr/include/qt4/QtCore 
-isystem/usr/share/qt4/mkspecs/linux-g++-64 
-isystem/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/27Faces-Retail.qtc-Qt-486-d423b044.05dbb98f/qt.headers 
-isystem/usr/include/qt4/QtNetwork 
-isystem/home/hkarel/CProjects/27FacesRetail/src/shared 
-isystem/home/hkarel/CProjects/27FacesRetail/src/shared/shared 
-isystem/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/SharedLib.qtc-Qt-486-d423b044.72e7795c/qt.headers 
-isystem/opt/opencv/3.3.0/include -isystem/opt/intel/caffe/1.0.2/include 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/cereal/1.1.1/include 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/jda/1.0.0/include 
-isystem/home/hkarel/CProjects/27FacesRetail/src/yaml/include 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/liblinear/1.0.0 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/pico/1.0.0 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/superviseddescent/0.4.1/include 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/eigen/3.2.8 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/vlfeat/0.9.20 
-isystem/home/hkarel/CProjects/27FacesRetail/src/3rdparty/vlfeat/0.9.20/vl 
-o 
/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/27Faces-Retail.qtc-Qt-486-d423b044.05dbb98f/.obj/73489b871e127538/moc_27fretail_appl.cpp.o 
-c 
/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/27Faces-Retail.qtc-Qt-486-d423b044.05dbb98f/qt.headers/moc_27fretail_appl.cpp


g++: error: unrecognized command line option ‘--param 
inline-unit-growth=120’



If I pass '-param inline-unit-growth = 120' without quotes in commsnd 
line - this errordoes not occur:


/usr/bin/g++ -O2 -Wall -Wextra *--param inline-unit-growth=120* -m64 
-pipe -fexceptions -fvisibility=default -std=c++11 -ggdb3 -Winline -Wall 
-Wextra -Wno-unused-parameter -DNDEBUG -DVERSION_PROJECT=0.9.13 
-DVERSION_PROJECT_MAJOR=0 -DVERSION_PROJECT_MINOR=9 
-DVERSION_PROJECT_PATCH=13 '-DGIT_REVISION="e3f7fd9"' 
-DQ_DATA_STREAM_VERSION=QDataStream::Qt_4_8 -DBPROTOCOL_VERSION_LOW=0 
-DBPROTOCOL_VERSION_HIGH=1 '-DUDP_SIGNATURE="27FR"' 
'-DCONFIG_DIR="27FacesRetail"' -DCPU_ONLY -DUSE_MKL -D_7ZIP_ST 
-D_7ZIP_ASM -DLZMA_COMPRESSION -DPPMD_COMPRESSION -DQT_CORE_LIB 
-DQT_NO_DEBUG -DQT_NETWORK_LIB 
-I/home/hkarel/CProjects/27FacesRetail/src/27fretaild 
-I/home/hkarel/CProjects/27FacesRetail/src 
-I/home/hkarel/CProjects/27FacesRetail/src/3rdparty 
-I/home/hkarel/CProjects/27FacesRetail/src/common 
-I/home/hkarel/CProjects/27FacesRetail/src/compression/src 
-I/usr/include/qt4 -I/usr/include/qt4/QtCore 
-I/usr/share/qt4/mkspecs/linux-g++-64 
-I/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/27Faces-Retail.qtc-Qt-486-d423b044.05dbb98f/qt.headers 
-I/usr/include/qt4/QtNetwork 
-I/home/hkarel/CProjects/27FacesRetail/src/shared 
-I/home/hkarel/CProjects/27FacesRetail/src/shared/shared 
-I/home/hkarel/CProjects/27FacesRetail/build/qtc_Qt_486_d423b044-release/SharedLib.qtc-Qt-486-d423b044.72e7795c/qt.headers 

[Qbs] How build 32 bit application on 64 host OS

2017-10-17 Thread Карелин Павел

Hi,

I'm working in Ubuntu 14.04, 64 bit. I use QtCreatir 4.4.1
Now I needed to build a small qbs project for two architectures: intel 
64 and 32 bits.
I have installed qt4 system libraries, 64 and 32 bits respectively. 
qmake - only 64 bits.
Simultaneously install the qmake to 64 and 32 bits - I can not, packages 
are mutually exclusive.

Tell me how to assemble the project simultaneously for 64 and 32 bits?

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


Re: [Qbs] How build 32 bit application on 64 host OS

2017-10-18 Thread Карелин Павел

Good afternoon, guys

Thank you for your responses. They gave me some food for thought.

Yesterday I spent half a day trying to substitute package qmake (from 64 
bit to 32 bit). But I did not achieve much success.
In addition to the problems with creating Qt-profile in QtCreator for 
qmake-32, were added problems with resolution of header files for 32 bit 
libraries. For me, it remains a mystery why header files for 32-bit 
libraries are located in /usr/lib/x86_64-linux-gnu directory, while the 
libraries themselves are in /usr/lib/i386-linux-gnu ...


The funny thing about this situation is that the program should work on 
OrangePi One (architecture armv7). But since OrangePi had an emulator 
for Intel architecture 32 bit (ExaGear), then I thought why should I not 
immediately compile a program for Intel-32 on my working computer...  So 
I started this adventure ...


While I decided to stay on the native assembly on OrangePi

--
BR, Pavel Karelin



18.10.2017 07:54, Christian Gagneraud пишет:

On 18/10/2017 12:09 AM, Christian Kandeler wrote:

On Tue, 17 Oct 2017 12:20:12 +0300 Карелин Павел <hka...@yandex.ru>
wrote:


I'm working in Ubuntu 14.04, 64 bit. I use QtCreatir 4.4.1 Now I
needed to build a small qbs project for two architectures: intel 64
and 32 bits. I have installed qt4 system libraries, 64 and 32 bits
respectively. qmake - only 64 bits. Simultaneously install the
qmake to 64 and 32 bits - I can not, packages are mutually
exclusive.


Hm, doesn't that mean that one of the two Qt installations is
incomplete with regards to developing for it? You cannot build qmake
projects with the 32-bit version either, right? At the moment, qmake
is our entry point for setting up the Qt modules using setup-qt. If
you are working on the command line only, you might get away with
installing the two packages one after the other (both with their
associated qmake), calling setup-qt while they are "complete".
However, in Qt Creator you always need the right qmake.


I have similar problem, and i'm starting to think that Ubuntu is 
broken (17.04).


You cannot even compile qt for x86_32 on a x86_64 host without 
breaking your distro due to package conflicts (Thiago told me it is 
doable on OpenSuse).


BTW, Qt has dropped linux-32 support starting with Qt-5.6 ...

I am now using a 32 bits VM in the mean time for my dev, If you build 
a 32 bits version of Qt within the 32 bits VM, then when you install 
it on linux-64 system it won't work, qmake cannot be run (something to 
do with rpath and/or ld.so), i have wasted lot of time on this, and i 
still don't have a solution.


Anyway, this is not a qbs-specific nor a qtc-specific problem, it is a 
qmake and/or ubuntu issue.


Карелин, you might want to resend your message to the "interest" 
mailing list.



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


Re: [Qbs] "Multi" Properties

2017-12-18 Thread Карелин Павел

OK, understood.
Thank you!

18.12.2017 14:15, Christian Kandeler пишет:

On Mon, 18 Dec 2017 14:04:21 +0300
Карелин Павел <hka...@yandex.ru> wrote:


In my project, I use the following construction:

      cpp.defines: {
      var def = [];
      if (project.simdDebug)
      def.push("SIMD_DEBUG");

      if (project.useSimd)
      def.push("USE_SIMD");

      return def;
      }

It works fine.
But I decided to experiment and do the same through "Properties"

      Properties {
      condition: project.simdDebug
      cpp.defines: outer.concat(["SIMD_DEBUG"])
      }
      Properties {
      condition: project.useSimd
      cpp.defines: outer.concat(["USE_SIMD"])
      }

As a result, I get either SIMD_DEBUG or USE_SIMD at the output, but not
both at once.
Is it possible to get both values immediately using "Properties"?

No, the Properties items form an implicit "else if" chain, so the conditions 
should be mutually exclusive if the same property appears in more than one of them. They 
are not well-suited for additive semantics like in your example.


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


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


[Qbs] "Multi" Properties

2017-12-18 Thread Карелин Павел

Hi,

In my project, I use the following construction:

    cpp.defines: {
    var def = [];
    if (project.simdDebug)
    def.push("SIMD_DEBUG");

    if (project.useSimd)
    def.push("USE_SIMD");

    return def;
    }

It works fine.
But I decided to experiment and do the same through "Properties"

    Properties {
    condition: project.simdDebug
    cpp.defines: outer.concat(["SIMD_DEBUG"])
    }
    Properties {
    condition: project.useSimd
    cpp.defines: outer.concat(["USE_SIMD"])
    }

As a result, I get either SIMD_DEBUG or USE_SIMD at the output, but not 
both at once.

Is it possible to get both values immediately using "Properties"?

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


[Qbs] Licensing of my own QBS modules

2017-11-21 Thread Карелин Павел

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?

--
BR, Pavel Karelin


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


[Qbs] qm-file build as internal resource

2017-12-11 Thread Карелин Павел

Hi,

I'm build a third-party project. The peculiarity of the project is that 
qm-files are represented as internal resources.

Now I solved the problem with a terrible hack:
1) Created the 'Translations' product
Product {
    name: "Translations"
    type: "qm"
    destinationDirectory: project.sourceDirectory + "/translations"

    Depends { name: "Qt.core" }
    files: ["*.ts"]
}

2) The results of the work 'Translations' are located in the 
project.sourceDirectory + "/translations" directory

3) The main product made dependent on 'Translations'
Depends { name: "Translations" }

4) In the main product I cling the created qm-files through a qrc-resource
    Group {
    name: "translations"
    files: ["translations/translations.qrc"]
    }

Is it possible to solve this task in another way?
qm-resources should be placed by the path ":translations/"

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


[Qbs] Linking dynamic library with version

2017-12-09 Thread Карелин Павел

Hi,

I need to connect the dynamic library 'soxr' to the QBS project.
The system has a symlink of libsoxr.so.0 (with the version), but not 
libsoxr.so

How can I connect to the project libsoxr.so.0?

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


Re: [Qbs] qm-file build as internal resource

2017-12-12 Thread Карелин Павел



12.12.2017 11:49, Christian Kandeler пишет:

On Mon, 11 Dec 2017 19:58:27 +0300
Карелин Павел <hka...@yandex.ru> wrote:


I'm build a third-party project. The peculiarity of the project is that
qm-files are represented as internal resources.
Now I solved the problem with a terrible hack:
1) Created the 'Translations' product
Product {
      name: "Translations"
      type: "qm"
      destinationDirectory: project.sourceDirectory + "/translations"

      Depends { name: "Qt.core" }
      files: ["*.ts"]
}

2) The results of the work 'Translations' are located in the
project.sourceDirectory + "/translations" directory
3) The main product made dependent on 'Translations'
Depends { name: "Translations" }

4) In the main product I cling the created qm-files through a qrc-resource
      Group {
      name: "translations"
      files: ["translations/translations.qrc"]
      }

Is it possible to solve this task in another way?
qm-resources should be placed by the path ":translations/"

You left out some details, so I have to take a guess. I assume you are listing the qm 
files "manually" in the qrc file, and that's what you want to get rid of?
In that case, something like the following looks adequate:

QtApplication { // Or whatever the main product is
 Group {
 name: "translations"
 files: ["/*.ts"]
 }
 Group {
 fileTagsFilter: ["qm"]
 fileTags: ["qt.core.resource_data"]
 }

 // See doc.qt.io/qbs/qt-modules.html#core-properties
 // for details.
 Qt.core.resourceSourceBase: Qt.core.qmDir
 Qt.core.resourcePrefix: "translations"
}

This should auto-generate the qrc file.
Christian, you were right in your guess. Indeed, the file 
translations.qrc is filled manually. Sorry that did not write about this 
at once. But unfortunately your recipe did not work. I see that qm-files 
are created in the assembly directory, but there is no resulting 
qrc-file. In addition, I have a couple more groups with resources. Will 
these groups be handled correctly?


    Group {
    name: "smileys"
    files: {
    var f = [];
    if (project.useSmileys === "yes")
    f = ["smileys/emojione.qrc"];
    else if (project.useSmileys === "min")
    f = ["smileys/smileys.qrc"];
    return f;
    }
    }

    Group {
    name: "resources"
    files: [
    "res.qrc",
    ]
    }


P.S. I can provide a link to the project on github, if that helps.




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

2018-06-18 Thread Карелин Павел

Hi,

I use only QBS (for both workers and for my own projects).
On the previous place of work through QBS I builded billing system (The 
project was quite voluminous, though simple in structure).
On the current work with QBS I successfully build the Caffe-framework 
(with NVIDIA GPU support).


It would be desirable that new versions of QBS appeared in the form of 
SNAP of packages. Now I was already accustomed to collect new versions 
of QBS at the assembly stands, but at the beginning of a way it was a 
big problem. I think that the need to compile QBS independently for 
Linux/Unix systems is one of the limiting factors (albeit not the most 
significant) in the transition to QBS.

Also I would like to have a QBS-SNAP package without GUI dependencies.

--
BR, Pavel Karelin


16.06.2018 06:58, Tino Pyssysalo пишет:


Hello everyone,

I’m Tino Pyssysalo, the new product owner of QBS at the Qt Company.

I’d like to conduct a small survey about QBS usage in the community to 
make investment and feature decisions to the product.


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.


Thanks in advance for everyone for helping me.

--

Best regards,

Tino Pyssysalo

Senior Manager

Product Management

The Qt Company

Hämeenkatu 14 C 25

33100 Tampere, Finland

tino.pyssys...@qt.io 

+358 40 8615475

http://qt.io 

The future is Written with Qt

---



___
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] Load qt-plugins

2017-12-21 Thread Карелин Павел

Hi, everyone

For my project, in addition to linking qt libraries, it also requires 
qt-plugins.
Where I can be placed the qt-plugins so that they can be seen the main 
qt libraries?


For example.
Main dir project: /opt/myproj
Qt-libs: /opt/myproj/lib

Where should the directory with plugins be located?

--
BR, Pavel Karelin

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


Re: [Qbs] Running a helper application right after it is build

2018-08-13 Thread Карелин Павел

I found a solution, but I would like to know how it is optimal:

    Product {
    id: sonnetParseTrigrams
    //type: "application"
    type: ["application", "sonnet-parse-trigrams-run"]
    consoleApplication: true
    destinationDirectory: "./bin"

    name: "SonnetParseTrigrams"
    targetName: "sonnet_parsetrigrams"

    Depends { name: "cpp" }
    Depends { name: "SonnetCore" }
    Depends { name: "Qt"; submodules: ["core"] }

    cpp.defines: sonnet.cppDefines

    cpp.cxxLanguageVersion: "c++14"
    cpp.cxxFlags: sonnet.cxxFlags

    files: [
    "data/parsetrigrams.cpp"
    ]

    Group {
    fileTagsFilter: "application"
    fileTags: "sonnet-parse-trigrams"
    }
    }

    Product {
    type: "sonnet-parse-trigrams-run"
    name: "SonnetParseTrigramsRun"
    Depends { name: "SonnetParseTrigrams" }
    }

    Rule {
    inputs: ["sonnet-parse-trigrams"]

    // no inputs -> just a generator
    //multiplex: true

    Artifact {
    fileTags: ["sonnet-parse-trigrams-run"]
    filePath: FileInfo.joinPaths(product.destinationDirectory, 
"trigrams.map")

    }
    prepare: {
    var runUtl = input.filePath;
    var sourceDir = FileInfo.joinPaths(product.sourceDirectory, 
"data/trigrams");
    var outputFile = 
FileInfo.joinPaths(product.destinationDirectory, "trigrams.map");


    console.info("=== runUtl ===");
    console.info(runUtl);
    console.info(sourceDir);
    console.info(outputFile);

    var cmd = new Command(runUtl, [sourceDir, outputFile]);
    cmd.description = 'sonnet parse trigrams ';
    cmd.highlight = "filegen";
    return cmd;

    }
    }


13.08.2018 18:47, Карелин Павел пишет:



13.08.2018 11:31, Christian Kandeler пишет:

On Sun, 12 Aug 2018 22:56:31 +0300
Карелин Павел  wrote:


I have a project in which, in addition to the main application,
auxiliary utilities are builded. In this regard, I have two questions:

1) How do I run an auxiliary utility right after his built, so that it
could generate necessary data?

It works the same way as always: You trigger creation of the data by giving it 
some tag, and the tool's tag appears as some sort of input in the respective 
rule (which has the data as outputs).

That's the problem, that I do not have clear how to do it.
Not so long ago I made a rule for compiling cuda-files. Here is a 
shortened version:


Module {
    id: cuda
    Depends { name: "cpp" }

    FileTagger {
    patterns: "*.cu"
    fileTags: ["cuda"]
    }

    Rule {
    id: cudaCompiler
    inputs: ["cuda"]
    auxiliaryInputs: ["hpp"]

    Artifact {
    fileTags: ["obj"]
    filePath: FileInfo.joinPaths(".obj", 
Utilities.getHash(input.baseDir), input.fileName + ".o")

    }

    prepare: {
    var args = [];
    args.push(...);

    var cmd = new Command("/usr/bin/nvcuda", args);
    cmd.description = 'cuda compiling ' + input.fileName;
    cmd.highlight = "compiler";
    return cmd;
    }
    }
}

Everything is clear: there are files with the extension 'cu', the 
files are connected to the project. And there is a cuda compiler: 
/usr/bin/nvcuda.


In the current project, instead of /usr/bin/nvcuda, the newly-built 
utility should be used (call it sonnet_parsetrigrams). I do not 
understand how to write it down. Also what should I write in the 
FileTagger section? Files do not have an extension, these files are 
not connected to the project. All that is - the name of the directory 
in which these files are located.  The call of the utility is as 
follows: sonnet_parsetrigrams MyProjectDir/trigramsDir > trigrams.map



2) How to pass parameters to the auxiliary utility? The matter is that
the utility has one parameter - a directory name. It directory contains
text files without expansion, the utility has to process these files.
The output should be one file with the extension 'map'

You rule has to take care of that when creating the Command.


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




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


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


[Qbs] Running a helper application right after it is build

2018-08-12 Thread Карелин Павел

Hi, guys

I have a project in which, in addition to the main application, 
auxiliary utilities are builded. In this regard, I have two questions:


1) How do I run an auxiliary utility right after his built, so that it 
could generate necessary data?
2) How to pass parameters to the auxiliary utility? The matter is that 
the utility has one parameter - a directory name. It directory contains 
text files without expansion, the utility has to process these files. 
The output should be one file with the extension 'map'


--
BR, Pavel Karelin

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


Re: [Qbs] Running a helper application right after it is build

2018-08-13 Thread Карелин Павел



13.08.2018 11:31, Christian Kandeler пишет:

On Sun, 12 Aug 2018 22:56:31 +0300
Карелин Павел  wrote:


I have a project in which, in addition to the main application,
auxiliary utilities are builded. In this regard, I have two questions:

1) How do I run an auxiliary utility right after his built, so that it
could generate necessary data?

It works the same way as always: You trigger creation of the data by giving it 
some tag, and the tool's tag appears as some sort of input in the respective 
rule (which has the data as outputs).

That's the problem, that I do not have clear how to do it.
Not so long ago I made a rule for compiling cuda-files. Here is a 
shortened version:


Module {
    id: cuda
    Depends { name: "cpp" }

    FileTagger {
    patterns: "*.cu"
    fileTags: ["cuda"]
    }

    Rule {
    id: cudaCompiler
    inputs: ["cuda"]
    auxiliaryInputs: ["hpp"]

    Artifact {
    fileTags: ["obj"]
    filePath: FileInfo.joinPaths(".obj", 
Utilities.getHash(input.baseDir), input.fileName + ".o")

    }

    prepare: {
    var args = [];
    args.push(...);

    var cmd = new Command("/usr/bin/nvcuda", args);
    cmd.description = 'cuda compiling ' + input.fileName;
    cmd.highlight = "compiler";
    return cmd;
    }
    }
}

Everything is clear: there are files with the extension 'cu', the files 
are connected to the project. And there is a cuda compiler: /usr/bin/nvcuda.


In the current project, instead of /usr/bin/nvcuda, the newly-built 
utility should be used (call it sonnet_parsetrigrams). I do not 
understand how to write it down. Also what should I write in the 
FileTagger section? Files do not have an extension, these files are not 
connected to the project. All that is - the name of the directory in 
which these files are located.  The call of the utility is as follows: 
sonnet_parsetrigrams MyProjectDir/trigramsDir > trigrams.map





2) How to pass parameters to the auxiliary utility? The matter is that
the utility has one parameter - a directory name. It directory contains
text files without expansion, the utility has to process these files.
The output should be one file with the extension 'map'

You rule has to take care of that when creating the Command.


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] Running a helper application right after it is build

2018-08-14 Thread Карелин Павел

Christian, thanks for the explanations

--
BR, Pavel Karelin


14.08.2018 14:53, Christian Kandeler пишет:

On Tue, 14 Aug 2018 14:27:35 +0300
Карелин Павел  wrote:


Today, with a fresh head, I decided to shorten the script a little (see
below). At me all has turned out - the project was builded. But last
night at me this version of the scenario hasn't earned, the problem was
that the rule for "sonnet-parse-trigrams-run" was executed earlier than
the utility sonnet_parsetrigrams was created (maybe I made a mistake
somewhere else ...)

That's not possible with the code you have pasted here. If the tool's tag is an 
input to a rule, then that rule will always wait for the rule which produces 
the tool.


I had a question: the rules for the "type" property are executed in the
same order as they are declared or they can be executed in parallel.

Everything is potentially run in parallel unless an ordering is introduced by a rule. You 
have such an ordering, because you tell qbs that "sonnet-parse-trigrams" is an 
input to your rule. Therefore, the application will be built before your rule runs.


      Product {
      id: sonnetParseTrigrams
      //type: "application"
      type: ["application", "sonnet-parse-trigrams-run"]
      consoleApplication: true
      destinationDirectory: "./bin"

      name: "SonnetParseTrigrams"
      targetName: "sonnet_parsetrigrams"

      Depends { name: "cpp" }
      Depends { name: "SonnetCore" }
      Depends { name: "Qt"; submodules: ["core"] }

      cpp.defines: sonnet.cppDefines

      cpp.cxxLanguageVersion: "c++14"
      cpp.cxxFlags: sonnet.cxxFlags

      files: [
      "data/parsetrigrams.cpp"
      ]

      Group {
      fileTagsFilter: "application"
      fileTags: "sonnet-parse-trigrams"
      }

      Rule {
      inputs: ["sonnet-parse-trigrams"]

      // no inputs -> just a generator
      //multiplex: true

      Artifact {
      fileTags: ["sonnet-parse-trigrams-run"]
      filePath:
FileInfo.joinPaths(product.destinationDirectory, "trigrams.map")
      }
      prepare: {
      var runUtl = input.filePath;
      var sourceDir =
FileInfo.joinPaths(product.sourceDirectory, "data/trigrams");
      var outputFile =
FileInfo.joinPaths(product.destinationDirectory, "trigrams.map");

      console.info("=== runUtl ===");
      console.info(runUtl);
      console.info(sourceDir);
      console.info(outputFile);

      var cmd = new Command(runUtl, [sourceDir,
outputFile]); cmd.description = "sonnet parse trigrams";
      cmd.highlight = "filegen";
      return cmd;
      }
      }
      }


14.08.2018 12:23, Christian Kandeler пишет:

On Tue, 14 Aug 2018 02:03:28 +0300
Карелин Павел  wrote:
  

I found a solution, but I would like to know how it is optimal:

Yes, that looks about right.
  

       Product {
       id: sonnetParseTrigrams
       //type: "application"
       type: ["application", "sonnet-parse-trigrams-run"]
       consoleApplication: true
       destinationDirectory: "./bin"

       name: "SonnetParseTrigrams"
       targetName: "sonnet_parsetrigrams"

       Depends { name: "cpp" }
       Depends { name: "SonnetCore" }
       Depends { name: "Qt"; submodules: ["core"] }

       cpp.defines: sonnet.cppDefines

       cpp.cxxLanguageVersion: "c++14"
       cpp.cxxFlags: sonnet.cxxFlags

       files: [
       "data/parsetrigrams.cpp"
       ]

       Group {
       fileTagsFilter: "application"
       fileTags: "sonnet-parse-trigrams"
       }
       }

       Product {
       type: "sonnet-parse-trigrams-run"
       name: "SonnetParseTrigramsRun"
       Depends { name: "SonnetParseTrigrams" }
       }

       Rule {
       inputs: ["sonnet-parse-trigrams"]

       // no inputs -> just a generator
       //multiplex: true

       Artifact {
       fileTags: ["sonnet-parse-trigrams-run"]
       filePath:
FileInfo.joinPaths(product.destinationDirectory, "trigrams.map")
       }
       prepare: {
       var runUtl = input.filePath;
       var sourceDir =
FileInfo.joinPaths(product.sourceDirectory, "data/trigrams");
       var outpu

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

2019-05-14 Thread Карелин Павел

+1

14.05.2019 11:54, Алексей Скородумов пишет:

Hi,

Is it hard to make "donate" button on "QBS site" as a part of 
"transition to community"?

I can't contribute time right now, but would like to support the project.

--
Best regards,
Aleksei Skorodumov

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


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


[Qbs] Construction project.buildDirectory

2019-12-19 Thread Карелин Павел

Hello

My colleague decided to try QtCreator 4.11 (QBS 1.15), and faced a problem.
At this project the QtCreator 4.11 issues a mistake:

import qbs
Project {
    minimumQbsVersion: "1.12.0"

    Probe {
    id: projectProbe

    readonly property string projectBuildDirectory: 
project.buildDirectory
    readonly property string projectSourceDirectory: 
project.sourceDirectory


    configure: {
    // ...
    }
    }
}


At the same time, on Qt Creator 4.10.2 this project opens normally.
Why is the "project.buildDirectory" construct no longer valid at the 
project level?


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


Re: [Qbs] Construction project.buildDirectory

2019-12-19 Thread Карелин Павел



19.12.2019 16:46, Christian Kandeler пишет:

On Thu, 19 Dec 2019 16:35:22 +0300
Карелин Павел  wrote:


My colleague decided to try QtCreator 4.11 (QBS 1.15), and faced a problem.
At this project the QtCreator 4.11 issues a mistake:

import qbs
Project {
      minimumQbsVersion: "1.12.0"

      Probe {
      id: projectProbe

      readonly property string projectBuildDirectory:
project.buildDirectory
      readonly property string projectSourceDirectory:
project.sourceDirectory

      configure: {
      // ...
      }
      }
}

Some code has been moved around to fix a different problem with Project-level 
probes, so this appears to be a side effect of that.
However, you can just leave off the "project.", and it will work both with 1.15 
and 1.14.
Yes, i did so. But I wanted to find out if the previous behavior would 
be restored. This is about syntactic sugar: I would like for the whole 
project to have a uniform construction of "project.buildDirectory"


--
Pavel




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] Construction project.buildDirectory

2020-02-06 Thread Карелин Павел

Richard, Christian, thanks for the information.
How will I have the opportunity to upgrade to the new version of QtC - I 
will  look at this fix


--
BR, Pavel Karelin


06.02.2020 18:44, Christian Kandeler пишет:

On Thu, 6 Feb 2020 16:08:42 +0100
Richard Weickelt  wrote:


sorry for breaking this. The issue has been fixed by
https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
Qt Creator 4.11.1 which is about to be released this week. You may try
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
the official release.

I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
was unfortunately made from an older commit. However,
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ contains an
updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
together with Qt Creator 4.12.0.

Plus, I suppose, an actual qbs 1.15.1 release with Creator 4.11.2.


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] Construction project.buildDirectory

2020-05-15 Thread Карелин Павел

Richard, Christian, hello.

I am in the process of moving from Ubuntu 14.04 to Ubuntu 20.04.
I got the opportunity to use QtC 4.11.2 and check your fix: access to 
project parameters through the prefix 'project'.

Everything works as expected, thanks for the fix.

--
BR, Pavel Karelin


06.02.2020 19:02, Карелин Павел пишет:

Richard, Christian, thanks for the information.
How will I have the opportunity to upgrade to the new version of QtC - 
I will  look at this fix


--
BR, Pavel Karelin


06.02.2020 18:44, Christian Kandeler пишет:

On Thu, 6 Feb 2020 16:08:42 +0100
Richard Weickelt  wrote:


sorry for breaking this. The issue has been fixed by
https://codereview.qt-project.org/c/qbs/qbs/+/289271  and the fix will be in
Qt Creator 4.11.1 which is about to be released this week. You may try
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/  or just wait for
the official release.

I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
was unfortunately made from an older commit. However,
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/  contains an
updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
together with Qt Creator 4.12.0.

Plus, I suppose, an actual qbs 1.15.1 release with Creator 4.11.2.


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




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


[Qbs] How to explicitly prohibit the use of qt-framework in project

2020-10-19 Thread Карелин Павел

Hi !

I need to check the build of the project for the case where qt-framework 
is not installed

For this I have created the following construction:

Depends { name: "Qt"; submodules: ["core", "network"]; required: false}
condition: Qt.core.present

Then in QtC I created a profile without qt-framework, and I tried to 
build the project. ... and the project was built.

It turned out that QBS found qt-framework on my system (Linux Kubuntu).

Question: to make the QBS strictly follow the the build profile, and 
does not look for qt-framework where they are not asked for it?


I use QBS 1.16

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


[Qbs] How to generate files like ui_main_window.h without buld all project.

2020-08-18 Thread Карелин Павел

Hello, colleagues

We wrote our own code checker to check uninitialized parameters in 
header files (this kind of check is not available in either GCC or 
Clang). Already several times such a check helped us out when especially 
hasty colleagues forgot to initialize the parameters.


But today, after another revision of the project, we stepped on a rake: 
for our utility to work, all dependencies (header files) must be 
present, but our utility is launched before the project is built, and UI 
files (like ui_main_window.h) are generated only during the build process.


Question: is it possible in any way to generate only UI files, without 
building the entire project?


Clarification: for our utility we are already using the generation of 
files of the form: "qbs generate -g clangdb ..." Perhaps there are 
already generators for the UI as well?


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


Re: [Qbs] How to generate files like ui_main_window.h without buld all project.

2020-08-18 Thread Карелин Павел
I will answer my own question myself: I consulted with my colleagues and 
we decided that code generation is not limited only to UI files. In 
general, a project can have a variety of code generators (bison/flex/sip 
and others). Therefore, we decided to change the order of building the 
project and checking initialization of variables.

This is a little unusual, but the end result is still achieved.

--
BR, Pavel Karelin

18.08.2020 10:45, Карелин Павел пишет:

Hello, colleagues

We wrote our own code checker to check uninitialized parameters in 
header files (this kind of check is not available in either GCC or 
Clang). Already several times such a check helped us out when 
especially hasty colleagues forgot to initialize the parameters.


But today, after another revision of the project, we stepped on a 
rake: for our utility to work, all dependencies (header files) must be 
present, but our utility is launched before the project is built, and 
UI files (like ui_main_window.h) are generated only during the build 
process.


Question: is it possible in any way to generate only UI files, without 
building the entire project?


Clarification: for our utility we are already using the generation of 
files of the form: "qbs generate -g clangdb ..." Perhaps there are 
already generators for the UI as well?


--
BR, Pavel Karelin

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


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


Re: [Qbs] How to explicitly prohibit the use of qt-framework in project

2020-10-20 Thread Карелин Павел



20.10.2020 09:04, Richard Weickelt пишет:

Hi,

you may try

 qbs build ...  moduleProviders.Qt.qmakeFilePaths:/invalid
Yes, it works. But is it possible to do such a disconnection from the 
project itself?
The fact is that I am developing a demo project, and I would like some 
products to be disabled when building, if the user does not have 
qt-framework installed.




to configure a non-existing location. You can also set this property in your 
profile if you like.


-Original Message-
From: "Карелин Павел" 
To: qbs@qt-project.org
Sent: Mon, 19 Oct 2020 20:26
Subject: [Qbs] How to explicitly prohibit the use of qt-framework in project

Hi !

I need to check the build of the project for the case where qt-framework
is not installed
For this I have created the following construction:

Depends { name: "Qt"; submodules: ["core", "network"]; required: false}
condition: Qt.core.present

Then in QtC I created a profile without qt-framework, and I tried to
build the project. ... and the project was built.
It turned out that QBS found qt-framework on my system (Linux Kubuntu).

Question: to make the QBS strictly follow the the build profile, and
does not look for qt-framework where they are not asked for it?

I use QBS 1.16

--
BR, Pavel Karelin


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


[Qbs] QBS script parsing speed

2020-06-30 Thread Карелин Павел

Hello.

Now I'm trying to write a QBS build script for a fairly large project 
(QGIS). After making every change to the build script - the project tree 
is rebuilt and QtCreator freezes for 10-15 seconds. It seems that 10-15 
is not so much, but since I have to make a lot of changes in the script, 
in the aggregate the slowdown turns out to be quite significant.
I suppose I was not the only one who faced a similar problem on large 
projects. I would like to know if any measures are being planned to 
increase the speed of re-parsing a project?

I am using QtCreator 4.11.2 (QBS 1.15.1)

--
BR, Pavel Karelin

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


Re: [Qbs] QBS script parsing speed

2020-06-30 Thread Карелин Павел

I already use the second variant.
The maximum that I export this:
    Export {
    Depends { name: "cpp" }
    cpp.includePaths: product.exportIncludePaths
    }

But to connect files, I use wildcard mask almost everywhere. In topic 
"Improving qbs resolve performance" 
(https://lists.qt-project.org/pipermail/qbs/2019-July/002481.html) 
Christian Kandeler does not recommend doing this. But now I can’t do it 
differently - there are a lots of files, and I can’t connect them all 
individually.


--
BR, Pavel Karelin


30.06.2020 11:24, Jochen Ulrich пишет:

We faced similar problems but our resolve times were even higher (30 s to 2 
mins).

We were able to work around this and significantly reduce the resolve times by 
avoiding transitive dependencies (meaning exporting dependencies).

So instead of this:

Product {
 name: “A”
 Depends { name: "B" }
}

Product {
 name: “B”
 Depends { name: "C" }
 Export {
 Depends { name: "C" }
 }
}

Product {
 name: “C”
 Depends { name: "SomeLibNeededEverywhere" }
 Export {
 Depends { name: "SomeLibNeededEverywhere" }
 }
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

You do it like this

Product {
 name: “A”
 Depends { name: "B" }
 Depends { name: "C" }
 Depends { name: "SomeLibNeededEverywhere" }
}

Product {
 name: “B”
 Depends { name: "C" }
 Depends { name: "SomeLibNeededEverywhere" }
}

Product {
 name: “C”
 Depends { name: "SomeLibNeededEverywhere" }
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Of course it is ugly because you have to maintain the transitive dependencies 
manually.
However, if you have cases where a dependency is needed in many places, you can 
create custom products that include it.
For example:
// qbs/imports/MyBaseApplication.qbs
CppApplication {
 Depends { name: "SomeLibNeededEverywhere" }
}

// in other .qbs files use MyBaseApplication instead of CppApplication
MyBaseApplication {
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

See also this thread on the mailing list:
https://lists.qt-project.org/pipermail/qbs/2019-July/002477.html
and the follow up:
https://lists.qt-project.org/pipermail/qbs/2019-August/002544.html

Kind regards
Jochen Ulrich


Von: Qbs  im Auftrag von Карелин Павел 

Datum: Dienstag, 30. Juni 2020 um 09:45
An: "qbs@qt-project.org" 
Betreff: [Qbs] QBS script parsing speed

Hello.

Now I'm trying to write a QBS build script for a fairly large project (QGIS). 
After making every change to the build script - the project tree is rebuilt and 
QtCreator freezes for 10-15 seconds.
It seems that 10-15 is not so much, but since I have to make a lot of changes 
in the script, in the aggregate the slowdown turns out to be quite significant.
I suppose I was not the only one who faced a similar problem on large projects. 
I would like to know if any measures are being planned to increase the speed of 
re-parsing a project?
I am using QtCreator 4.11.2 (QBS 1.15.1)


--
BR, Pavel Karelin


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


Re: [Qbs] QBS script parsing speed

2020-07-01 Thread Карелин Павел
I updated QtC to version 4.12.3 (QBS 1.16.0). After that, parsing my 
project from scratch took 4-7 seconds. With this times  is possible to 
work quite comfortably. Thanks for speeding up! :)))


--
BR, Pavel Karelin


30.06.2020 18:09, Jochen Ulrich пишет:

Nice!
It brings a ~44% speed improvement in the problematic case according to your 
numbers:

Resolving withLeafExports/9-2-implicit

real0m43.592s
real0m24.494s

Thanks, Richard!

So for "medium" projects in terms of depth of the dependency tree, it's 
sensible to use transitive dependencies now:
withLeafExports/4-8-implicit:
real0m18.180s
vs.
withAdditionalDepends/4-8-explicit:
real0m19.319s

However, for "large" projects, the workaround still seems to be 25% faster:
withLeafExports/9-2-implicit:
real0m24.494s
vs.
withAdditionalDepends/9-2-explicit:
real0m18.149s


Best
Jochen
  


Am 30.06.20, 15:09 schrieb "Richard Weickelt" :

 Jochen,

 >> Well [the time] goes into "Handling Products". So it is 
ModuleLoader::handleProduct().
 >> And there, it could be the ModuleMerger. But speculation is dangerous 
when discussing about performance.
 > See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html
 >
 > You can find my test results together with the scripts to generate the 
projects here:
 > 
https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md

 Then you might be happy to hear that the ModuleMerger was completely
 rewritten for Qbs 1.16.0
 (https://codereview.qt-project.org/c/qbs/qbs/+/284737). Running your
 benchmark with Qbs 1.16.0 (Qt Creator 4.12) gives me significantly better
 results in case of transitive dependencies. See below.

 I am not sure whether this has any noticable effect on real-world projects.
 But if ModuleMerger was ever a bottleneck, then it should not longer be.

 -
 i5-2520M CPU @ 2.50GHz Xubuntu 16.04)
 First line: Qbs 1.15.1
 Second line: Qbs 1.16.0

 > Resolving 4-8-direct
 real0m3.089s
 real0m2.669s

 > Resolving 4-8-implicit
 real0m4.808s
 real0m3.409s

 > Resolving 4-8-explicit
 real0m3.898s
 real0m3.085s

 > Resolving withLeafExports/4-8-direct
 real0m16.508s
 real0m13.793s

 > Resolving withLeafExports/4-8-implicit
 real0m25.907s
 real0m18.180s

 > Resolving withLeafExports/4-8-explicit
 real0m21.393s
 real0m15.844s

 > Resolving withLeafExports/9-2-direct
 real0m13.992s
 real0m10.750s

 > Resolving withLeafExports/9-2-implicit
 real0m43.592s
 real0m24.494s

 > Resolving withLeafExports/9-2-explicit
 real0m26.019s
 real0m17.589s

 > Resolving withAdditionalDepends/4-8-direct
 real0m25.096s
 real0m18.892s

 > Resolving withAdditionalDepends/4-8-implicit
 real0m28.369s
 real0m19.868s

 > Resolving withAdditionalDepends/4-8-explicit
 real0m29.164s
 real0m19.319s

 > Resolving withAdditionalDepends/9-2-direct
 real0m19.110s
 real0m17.264s

 > Resolving withAdditionalDepends/9-2-implicit
 real0m20.887s
 real0m19.269s

 > Resolving withAdditionalDepends/9-2-explicit
 real0m18.359s
 real0m18.149s

 > Resolving 9-2-direct
 real0m2.500s

 > Resolving 9-2-implicit
 real0m6.393s

 > Resolving 9-2-explicit
 real0m3.833s
 real0m2.326s



___
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] Rule.Return dynamic list for outputArtifacts

2020-07-23 Thread Карелин Павел
Having weighed all the "pros" and "cons", I have decided not to use 
qbs.Process in outputArtifacts. Now I settled on a stupidly-simple 
solution: I reduced the number of generated files from 6 to 5. The 
increase in compilation time in the assembly scale of a large project is 
almost imperceptible.


Nevertheless, I want to thank Christian and Richard for their advices. 
Now I know a little more about QBS :-)


--
BR, Pavel Karelin


21.07.2020 18:42, Christian Kandeler пишет:

On Tue, 21 Jul 2020 18:32:10 +0300
Карелин Павел  wrote:


How can I execute Command from outputArtifacts?

You can't, you need to use a JavaScript command and qbs.Process.


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] Rule.Return dynamic list for outputArtifacts

2020-07-24 Thread Карелин Павел



23.07.2020 14:34, Christian Kandeler пишет:

On Thu, 23 Jul 2020 14:13:13 +0300
Карелин Павел  wrote:


Having weighed all the "pros" and "cons", I have decided not to use
qbs.Process in outputArtifacts. Now I settled on a stupidly-simple
solution: I reduced the number of generated files from 6 to 5.

But how do you know there will never be fewer than that?
I don’t know. Therefore, I called this decision stupid. I'll leave it 
like this for now, until the next rakes ;)


P.S.
It's just that now there are other problems which eat out my brain, so 
let it stay for now j=5





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


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


[Qbs] Rule.Return dynamic list for outputArtifacts

2020-07-21 Thread Карелин Павел

Hello.

I recently needed to develop a rule for a sip generator (see below). 
Basically, the rule works well, but yesterday it failed. At the output, 
sip-generator create 6 cpp-files of the following format: 
sip_corepartX.cpp (this is justified from the point of view of parallel 
compilation, cpp-file sizes can be tens of megabytes). These 6 cpp-files 
are reflected in the outputArtifacts parameter. However, yesterday I 
came across a small sip-file, and the generated cpp-files turned out to 
be not 6, but only 5. Naturally, my rule failed.


Question: how can I resolve my situation?
Of course, I can tell the sip-generator to create fewer cpp-files 
(parameter -j), but I would like to understand - are there other ways?

For example, to ignore section
{
filePath: generatedFilesDir + "/sip" + moduleSipName + "part5.cpp",
   fileTags: ["cpp"],
   cpp: {
 cxxFlags: sipCxxFlags
   }
}
if the file ("sip" + moduleSipName + "part5.cpp") does not exist

--
BR, Pavel Karelin

    Rule {
    multiplex: true
    inputs: ["sip"]
    outputFileTags: ["cpp", "hpp", "pyi"]
    outputArtifacts: {
    var baseSipFile = product.sip.baseSipFile;
    var moduleSipName = product.sip.moduleSipName
    var generatedFilesDir = product.sip.generatedFilesDir

    var baseSipName = FileInfo.baseName(baseSipFile);

    //console.info("sip_corepart: " + generatedFilesDir + 
"/sip" + moduleSipName + "part0.cpp")

    //console.info("sip 1 :")

    var sipCxxFlags = [
    "-Wno-deprecated-declarations",
    "-Wno-deprecated",
    "-Wno-unused-variable",
    "-Wno-switch",
    //"-Wno-unused-function",
    //"-Wno-unused-but-set-variable",
    //"-Wno-unused-parameter",
    ]

    return [{ // sip_corepart0.cpp
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part0.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part1.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part2.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part3.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part4.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{
    filePath: generatedFilesDir + "/sip" + moduleSipName + 
"part5.cpp",

    fileTags: ["cpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{ // sipAPI_core.h
    filePath: generatedFilesDir + "/sipAPI" + moduleSipName 
+ ".h",

    fileTags: ["hpp"],
    cpp: {
    cxxFlags: sipCxxFlags
    }
    },{ // core.pyi
    filePath: project.buildDirectory + "/python/" + 
baseSipName + ".pyi",

    fileTags: ["pyi"],
    }];
    }

    prepare: {
    var baseSipFile = product.sip.baseSipFile;
    var moduleSipName = product.sip.moduleSipName;
    var generatedFilesDir = product.sip.generatedFilesDir;

    var baseSipName = FileInfo.baseName(baseSipFile);

    // usr/bin/sip -w -e -x ANDROID -x ARM -x MOBILITY_LOCATION 
-n sip -t WS_X11 -t Qt_5_12_4 -g -o

    // -a /home/hkarel/CProjects/QGIS/build2/python/qgis.core.api
    // -n sip
    // -y 
/home/hkarel/CProjects/QGIS/build2/output/python/qgis/core.pyi

    // -j 6
    // -c /home/hkarel/CProjects/QGIS/build2/python/core
    // -I /home/hkarel/CProjects/QGIS/build2/python/core
    // -I /usr/share/sip/PyQt5
    // /home/hkarel/CProjects/QGIS/build2/python/core/core.sip

    var args = ["-w", "-e", "-g", "-o", "-j", "6", "-n", "sip"];
    args = args.concat(["-x", "ANDROID", "-x", "ARM", "-x", 
"MOBILITY_LOCATION"]);

    args = args.concat(["-t", "WS_X11", "-t", "Qt_5_12_4"])

    args.push("-c");
    args.push(generatedFilesDir);

    args.push("-I");
    args.push(generatedFilesDir);

    args.push("-I");
    args.push(project.buildDirectory + "/python");

    args.push("-I");
    args.push("/usr/share/sip/PyQt5");

    args.push("-y");
 

Re: [Qbs] Rule.Return dynamic list for outputArtifacts

2020-07-21 Thread Карелин Павел



21.07.2020 16:45, Christian Kandeler пишет:

On Tue, 21 Jul 2020 15:10:38 +0300
Карелин Павел  wrote:


I recently needed to develop a rule for a sip generator (see below).
Basically, the rule works well, but yesterday it failed. At the output,
sip-generator create 6 cpp-files of the following format:
sip_corepartX.cpp (this is justified from the point of view of parallel
compilation, cpp-file sizes can be tens of megabytes). These 6 cpp-files
are reflected in the outputArtifacts parameter. However, yesterday I
came across a small sip-file, and the generated cpp-files turned out to
be not 6, but only 5. Naturally, my rule failed.

Question: how can I resolve my situation?

Do I understand you correctly that you don't really know in advance how many 
files will be generated, i.e. the -j parameter just specifies a maximum?

Yes, exactly

Then you either need to find a way to find out the value beforehand (by 
analyzing the input in some way), or, if that is not possible, you cheat and 
call the tool already in the outputArtifactsScript; the prepare script then 
just sets up a dummy command.

How can I execute Command from outputArtifacts?


Note that this loses concurrency, as rule execution happens in the main thread. 
But this might be acceptable for short-running tools.


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


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


Re: [Qbs] How to explicitly prohibit the use of qt-framework in project

2020-10-21 Thread Карелин Павел


> You mean in the project files? You can do that only on Product level, not
> for the entire project:

Yes, it was about the Product, I misspelled.
This is what I did, works as I need

Product {
    ...
    Depends { name: "Qt"; submodules: ["core", "network"]; required: false}

    moduleProviders.Qt.qmakeFilePaths: "/invalid"
    condition: Qt.core.present
    ...
}

Colleagues, thank you for your help!

--
BR, Pavel


20.10.2020 23:48, Richard Weickelt пишет:

 qbs build ...  moduleProviders.Qt.qmakeFilePaths:/invalid

Yes, it works. But is it possible to do such a disconnection from the
project itself?

You mean in the project files? You can do that only on Product level, not
for the entire project:

Project {
// cannot set global moduleProvider here.


 CppApplication {
 // 

 moduleProviders.Qt.qmakeFilePaths: "/invalid"
 }
}


The fact is that I am developing a demo project, and I would like some
products to be disabled when building, if the user does not have
qt-framework installed.

I still don't get what you want to show. How Qbs behaves when Qt is not
found? You could also simply create two profiles:

1. with moduleProviders.Qt.qmakeFilePaths not set or set to a a valid path,
2. with moduleProviders.Qt.qmakeFilePaths set to invalid.

And then invoke Qbs with the two different profiles.


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


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

2021-02-09 Thread Карелин Павел

Hello!

I need to build  components of the project  in a specific sequence:
1) Build of auxiliary generator program;
2) Generate a resource file using the generator received in step 1;
3) Add the resource file obtained in step 2 to project QRC-file;
4) Build the main project program with the QRC-file obtained in step 3.

I previously asked a similar question 
(https://lists.qt-project.org/pipermail/qbs/2018-August/002223.html),
and how to perform steps 1, 2 I know roughly. However, this decision 
seems to me to be somewhat confusing (not transparent),
so I wanted to know maybe at the moment there is a simpler (transparent) 
solution.


I have no understanding of how, after points 1,2 to be followed points 3 
and 4, so I ask for help with the solution.


--
Best regards,
Pavel Karelin

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


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

2021-02-10 Thread Карелин Павел

This morning I tried the following solution (see below). got this error

:-1: ошибка: The process 
'/home/hkarel/CProjects/QGit/build/Debug/bin/sonnet_parsetrigrams'

could not be started: execve: Permission denied.
The full command line invocation was: 
/home/hkarel/CProjects/QGit/build/Debug/bin/sonnet_parsetrigrams
/home/hkarel/CProjects/QGit/src/spellcheck/sonnet/trigrams 
/home/hkarel/CProjects/QGit/build/Debug/trigrams.map


I assumed that the sonnet_parsetrigrams helper appl would be built 
earlier than needed in the idtrigrams rule, but that didn't work.



--- qgit_project.qbs ---
import qbs
import "qbs/imports/QbsUtl/qbsutl.js" as QbsUtl

Project {
    name: "QGit (Project)"
    minimumQbsVersion: "1.18.0"
    qbsSearchPaths: ["qbs"]
    ...
    references: [
    "src/qgit.qbs",
    "src/spellcheck/sonnet/parsetrigrams.qbs",
    ]
}

--- parsetrigrams.qbs ---
import qbs
import qbs.FileInfo

Product {
    name: "SonnetParseTrigrams"
    targetName: "sonnet_parsetrigrams"
    condition: true

    type: "application"
    destinationDirectory: "./bin"

    Depends { name: "cpp" }
    Depends { name: "Qt"; submodules: ["core"] }

    cpp.defines: project.cppDefines
    cpp.cxxFlags: project.cxxFlags
    cpp.cxxLanguageVersion: project.cxxLanguageVersion

    // This declaration is needed to suppress Qt warnings
    cpp.systemIncludePaths: Qt.core.cpp.includePaths

    files: [
    "parsetrigrams.cpp"
    ]
}

--- qgit.qbs ---
import qbs
import qbs.FileInfo

Product {
    name: "QGit"
    targetName: "qgit"

    type: "application"
    destinationDirectory: "./bin"

    Depends { name: "cpp" }
    Depends { name: "SonnetParseTrigrams" }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    

    Group {
    fileTags: "trigrams"
    //files: FileInfo.joinPaths(project.buildDirectory, "*.trgmap")
    //files: "spellcheck/sonnet/trigrams/*.trg"
    files: 
"/home/hkarel/CProjects/QGit/src/spellcheck/sonnet/trigrams/*"

    }
    Group {
    fileTagsFilter: ["trigrams-map"]
    //fileTagsFilter: ["sonnet-parse-trigrams-run"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams1"
    Qt.core.resourcePrefix: "trigrams1"

    Rule {
    inputs: ["trigrams"]
    multiplex: true

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(product.buildDirectory, 
"trigrams.map")

    }
    prepare: {
    //var runUtl = input.filePath;
    var runUtl = FileInfo.joinPaths(project.buildDirectory, 
"bin/sonnet_parsetrigrams");
    var sourceDir = FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams");
    var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"trigrams.map");


    console.info("=== runUtl ===");
    console.info(input);
    console.info(inputs);
    console.info(runUtl);
    console.info(sourceDir);
    console.info(outputFile);

    var cmd = new Command(runUtl, [sourceDir, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }
}

--
Pavel



09.02.2021 20:33, Карелин Павел пишет:



09.02.2021 16:06, Christian Kandeler пишет:

On 2/9/21 1:04 PM, Карелин Павел wrote:

Hello!

I need to build  components of the project  in a specific sequence:
1) Build of auxiliary generator program;
2) Generate a resource file using the generator received in step 1;
3) Add the resource file obtained in step 2 to project QRC-file;
4) Build the main project program with the QRC-file obtained in step 3.

I previously asked a similar question 
(https://lists.qt-project.org/pipermail/qbs/2018-August/002223.html),
and how to perform steps 1, 2 I know roughly. However, this decision 
seems to me to be somewhat confusing (not transparent),
so I wanted to know maybe at the moment there is a simpler 
(transparent) solution.


I have no understanding of how, after points 1,2 to be followed 
points 3 and 4, so I ask for help with the solution. 


If by "add the resource file" you mean you have a hand-written qrc 
file and you want to merge a generated file into it, then that's not 
possible (unless you do the merging "manually" in a dedicated rule 
and tag the result afterwards). However, if you do it "correctly" by 
having the qrc file be auto-generated from files tagged as resource 
data, then the whole thing is straightforward.


You might 

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

2021-02-10 Thread Карелин Павел

Hi, Alberto, colleagues

At first, your recipe with
  type: ["application", "trigrams-generator"]
and
  Depends { productTypes: ["trigrams-generator"] }
helped me, the project was built.

But then I found out that the assembly of the project depends on the 
order of declaring sections 'Depends'


This is how the project is build:
    Depends { name: "cpp" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "SharedLib" }
    Depends { name: "Yaml" }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

But this is no longer:
    Depends { name: "cpp" }
    Depends { name: "SharedLib" }
    Depends { name: "Yaml" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

The presence of the 'explicitlyDependsOnFromDependencies' directive does 
not solve the problem.
I am attaching qbs-files of the project, so that can more accurately 
evaluate them.


The project itself is located here: https://github.com/hkarel/qgit.git
Branch: 3x-spellcheck
Commit: 50285c7aea2c8546cf95a531e645c18dd1e1ab8e

Remark: the utility for generating the trigram-file has been slightly 
redesigned.
Now instead of one map-file, a file is generated for each language. 
Accordingly, the QBS-rule has changed slightly.


--
Pavel


10.02.2021 17:54, Alberto Mardegan пишет:

Just got some more thoughts:

On 10/02/21 11:48, Карелин Павел wrote:

--- parsetrigrams.qbs ---
import qbs
import qbs.FileInfo

Product {
     name: "SonnetParseTrigrams"
     targetName: "sonnet_parsetrigrams"
     condition: true

     type: "application"

You can add an additional type here, like

 type: ["application", "trigram-generator"]

And then:


--- qgit.qbs ---
import qbs
import qbs.FileInfo

Product {
     name: "QGit"
     targetName: "qgit"

     type: "application"
     destinationDirectory: "./bin"

     Depends { name: "cpp" }
     Depends { name: "SonnetParseTrigrams" }
     Depends { name: "Qt"; submodules: ["core", "widgets"] }

Here add

 Depends { productTypes: ["trigram-generator"] }

and in your Rule add

 explicitlyDependsOnFromDependencies: ["trigram-generator"]

I'm not 100% sure that the last one is needed, but it seems to make
sense :-)

Ciao,
   Alberto



import qbs
import "qbs/imports/QbsUtl/qbsutl.js" as QbsUtl

Project {
name: "QGit (Project)"
minimumQbsVersion: "1.18.0"
qbsSearchPaths: ["qbs"]

readonly property string minimumQtVersion: "5.12.6"
readonly property bool conversionWarnEnabled: true

readonly property var projectVersion: projectProbe.projectVersion
readonly property string projectGitRevision: projectProbe.projectGitRevision

Probe {
id: projectProbe
property var projectVersion;
property string projectGitRevision;

readonly property string projectBuildDirectory:  buildDirectory
readonly property string projectSourceDirectory: sourceDirectory

configure: {
projectVersion = QbsUtl.getVersions(projectSourceDirectory + 
"/VERSION");
projectGitRevision = QbsUtl.gitRevision(projectSourceDirectory);
//if (File.exists(projectBuildDirectory + "/package_build_info"))
//File.remove(projectBuildDirectory + "/package_build_info")
}
}

property var cppDefines: {
var def = [
"VERSION_PROJECT=\"" + projectVersion[0] + "\"",
"VERSION_PROJECT_MAJOR=" + projectVersion[1],
"VERSION_PROJECT_MINOR=" + projectVersion[2],
"VERSION_PROJECT_PATCH=" + projectVersion[3],
"GIT_REVISION=\"" + projectGitRevision + "\"",
"LOGGER_LESS_SNPRINTF",
];

if (qbs.buildVariant === "release")
def.push("NDEBUG");

if (qbs.targetOS.contains("windows")
&& qbs.toolchain && qbs.toolchain.contains("mingw"))
{
def.push("CONFIG_DIR=\"ProgramData/qgit/config\"");
}
else
def.push("CONFIG_DIR=\"~/.config/qgit\"");

return def;
}

property var cxxFlags: [
"-ggdb3",
//"-Winline",
"-Wall",
"-Wextra",
"-Wno-unused-parameter",
"-Wno-variadic-macros",
]
property string cxxLanguageVersion: "c++17"

references

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

2021-03-02 Thread Карелин Павел



02.03.2021 12:00, Иван Комиссаров пишет:

Hello!. In the second variant - do you need

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

?

Yes, need it. Without this, there will be an error:
TypeError: Result of expression 
'explicitlyDependsOn["trigrams-generator"]' [undefined] is not an object.



The product has that type already

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

1 марта 2021 г., в 21:43, Карелин Павел <mailto:hka...@yandex.ru>> написал(а):


Colleagues, hello.

It's a bit of a pity that I didn't get an answer to the last 
question, but it's okay.  There is a working option, and it can be used.

Christian, Alberto, thanks for helping to solve my problem.

--
BR, Pavel


22.02.2021 19:07, Карелин Павел пишет:

Christian, I experimented a little, and got another variant.

Your variant (clarification: the generation of trigrams in binary 
form is performed by the parsetrigrams utility) :


Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]

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

Product {
    name: "QGit"
    targetName: "qgit"

    type: "application"

    Depends { name: "cpp" }
    Depends { name: "ParseTrigrams" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "trigrams", 
input.baseName + ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

My variant:

Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application", "trigrams-generator"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]
    Group {
    fileTagsFilter: "application"
    fileTags: "trigrams-generator"
    }
}

Product {
    name: "QGit"

    type: "application"

    Depends { name: "cpp" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "trigrams", 
input.baseName + ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

The differences are as follows:
For ParseTrigrams:
    type: ["application"]
vs
    type: ["application", "trigrams-generator"]

For QGit:
   

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

2021-03-01 Thread Карелин Павел

Colleagues, hello.

It's a bit of a pity that I didn't get an answer to the last question, 
but it's okay.  There is a working option, and it can be used.

Christian, Alberto, thanks for helping to solve my problem.

--
BR, Pavel


22.02.2021 19:07, Карелин Павел пишет:

Christian, I experimented a little, and got another variant.

Your variant (clarification: the generation of trigrams in binary form 
is performed by the parsetrigrams utility) :


Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]

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

Product {
    name: "QGit"
    targetName: "qgit"

    type: "application"

    Depends { name: "cpp" }
    Depends { name: "ParseTrigrams" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "trigrams", input.baseName 
+ ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

My variant:

Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application", "trigrams-generator"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]
    Group {
    fileTagsFilter: "application"
    fileTags: "trigrams-generator"
    }
}

Product {
    name: "QGit"

    type: "application"

    Depends { name: "cpp" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "trigrams", input.baseName 
+ ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
        cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

The differences are as follows:
For ParseTrigrams:
    type: ["application"]
vs
    type: ["application", "trigrams-generator"]

For QGit:
    Depends { name: "ParseTrigrams" }
    Depends { productTypes: ["trigrams-generator"] }
vs
    Depends { productTypes: ["trigrams-generator"] }


I would like to know if there is a fundamental difference in these 
solutions, and which variant is preferable?


--
BR, Pavel



22.02.2021 13:00, Christian Kandeler пишет:

On 2/19/21 5:43 PM, Карелин Павел wrote:

Project QGit__micro is attached.
The situation is reproduced 


I've attached the corrected qbs files.



Christian


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



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


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


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

2021-02-19 Thread Карелин Павел

Colleagues, developers of qbs, I still need help solving this problem.
The solution suggested by Alberto looks clear, but unfortunately it 
works with a 50/50 probability.
I would like to understand: an error in the proposed solution or it a 
bug of QBS?


The project itself is located here: https://github.com/hkarel/qgit.git
Branch: 3x-spellcheck
If you are uncomfortable working with this project, I can create a 
micro-project that emulates this situation.


--
BR, Pavel


11.02.2021 10:58, Карелин Павел пишет:

Hi, Alberto, colleagues

At first, your recipe with
  type: ["application", "trigrams-generator"]
and
  Depends { productTypes: ["trigrams-generator"] }
helped me, the project was built.

But then I found out that the assembly of the project depends on the 
order of declaring sections 'Depends'


This is how the project is build:
    Depends { name: "cpp" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "SharedLib" }
    Depends { name: "Yaml" }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

But this is no longer:
    Depends { name: "cpp" }
    Depends { name: "SharedLib" }
    Depends { name: "Yaml" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

The presence of the 'explicitlyDependsOnFromDependencies' directive 
does not solve the problem.
I am attaching qbs-files of the project, so that can more accurately 
evaluate them.


The project itself is located here: https://github.com/hkarel/qgit.git
Branch: 3x-spellcheck
Commit: 50285c7aea2c8546cf95a531e645c18dd1e1ab8e

Remark: the utility for generating the trigram-file has been slightly 
redesigned.
Now instead of one map-file, a file is generated for each language. 
Accordingly, the QBS-rule has changed slightly.


--
Pavel


10.02.2021 17:54, Alberto Mardegan пишет:

Just got some more thoughts:

On 10/02/21 11:48, Карелин Павел wrote:

--- parsetrigrams.qbs ---
import qbs
import qbs.FileInfo

Product {
     name: "SonnetParseTrigrams"
     targetName: "sonnet_parsetrigrams"
     condition: true

     type: "application"

You can add an additional type here, like

 type: ["application", "trigram-generator"]

And then:


--- qgit.qbs ---
import qbs
import qbs.FileInfo

Product {
     name: "QGit"
     targetName: "qgit"

     type: "application"
     destinationDirectory: "./bin"

     Depends { name: "cpp" }
     Depends { name: "SonnetParseTrigrams" }
     Depends { name: "Qt"; submodules: ["core", "widgets"] }

Here add

 Depends { productTypes: ["trigram-generator"] }

and in your Rule add

 explicitlyDependsOnFromDependencies: ["trigram-generator"]

I'm not 100% sure that the last one is needed, but it seems to make
sense :-)

Ciao,
   Alberto




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


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


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

2021-02-19 Thread Карелин Павел

Project QGit__micro is attached.
The situation is reproduced


19.02.2021 19:20, Jochen Ulrich пишет:

I can create a micro-project that emulates this situation.

Yeah I think this would help. It might even help you understand what exactly 
triggers the issue and then it's easier to determine if this is a Qbs bug or a 
problem in your project.

Best
Jochen Ulrich


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


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

2021-02-11 Thread Карелин Павел



11.02.2021 19:26, Alberto Mardegan пишет:

On 11/02/21 10:58, Карелин Павел wrote:

But then I found out that the assembly of the project depends on the
order of declaring sections 'Depends'

Unfortunately I don't have a recent enough version of QBS (still at
1.16), so I'm unable to try your project, but can you please paste the
error you get this time?

I made another comit with the downgrade of QBS to 1.16


Does the SharedLib depend on the generator, or on resource files?

No, it doesn't, it's just a static library.
To build the project, you also need libhunspell-dev



Ciao,
   Alberto



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


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

2021-02-22 Thread Карелин Павел

Christian, I experimented a little, and got another variant.

Your variant (clarification: the generation of trigrams in binary form 
is performed by the parsetrigrams utility) :


Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]

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

Product {
    name: "QGit"
    targetName: "qgit"

    type: "application"

    Depends { name: "cpp" }
    Depends { name: "ParseTrigrams" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

My variant:

Product {
    name: "ParseTrigrams"
    targetName: "parsetrigrams"

    type: ["application", "trigrams-generator"]
    ...
    files: [
    "parsetrigrams.cpp"
    ]
    Group {
    fileTagsFilter: "application"
    fileTags: "trigrams-generator"
    }
}

Product {
    name: "QGit"

    type: "application"

    Depends { name: "cpp" }
    Depends { productTypes: ["trigrams-generator"] }
    Depends { name: "Qt"; submodules: ["core", "widgets"] }

    Group {
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
        cmd.highlight = "filegen";
    return cmd;
    }
    }

    files: [
    "qgit.cpp",
    ]
}

The differences are as follows:
For ParseTrigrams:
    type: ["application"]
vs
    type: ["application", "trigrams-generator"]

For QGit:
    Depends { name: "ParseTrigrams" }
    Depends { productTypes: ["trigrams-generator"] }
vs
    Depends { productTypes: ["trigrams-generator"] }


I would like to know if there is a fundamental difference in these 
solutions, and which variant is preferable?


--
BR, Pavel



22.02.2021 13:00, Christian Kandeler пишет:

On 2/19/21 5:43 PM, Карелин Павел wrote:

Project QGit__micro is attached.
The situation is reproduced 


I've attached the corrected qbs files.



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] Dynamic generation of the resource file

2021-10-08 Thread Карелин Павел

Hi.

Ivan, only now have "reached the hands" to see your decision. Everything 
turned out, the only thing at first I created two separate rules 
(according to the rule for each group). It looked like a flaw. However, 
then I figured out how to make a universal rule. See comment-section 
"Variant 1" and "Variant 2" in the attached file.


Denis, Ivan, thank you for your help in solving this problem!

BR, Pavel


03.10.2021 13:07, Иван Комиссаров пишет:

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

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

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

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


Ivan

2 окт. 2021 г., в 17:01, Карелин Павел <mailto:hka...@yandex.ru>> написал(а):


Denis, if you can suggest how to generate a second resource file - I 
will only be glad.


Now I assume that the name of the dynamic resource file depends on 
the parameters

  Qt.core.resourceFileBaseName: "trigrams"
  Qt.core.resourcePrefix: "trigrams"

And I don't understand how to specify another file name.

--
Pavel

02.10.2021 09:17, Denis Shienkov пишет:




import qbs
import qbs.FileInfo
import QbsUtl
import ProbExt

Product {
name: "Processing"
targetName: "fns-processing"
condition: true

type: "application"
destinationDirectory: "./bin"

Depends { name: "cpp" }
Depends { name: "lib.sodium" }
Depends { name: "lib.onnxruntime" }
Depends { name: "Commands" }
Depends { name: "PProto" }
Depends { name: "RapidJson" }
Depends { name: "SharedLib" }
Depends { name: "Yaml" }
Depends { name: "Qt"; submodules: ["core", "network"] }

Depends { productTypes: ["appl-encryptor"] }

lib.onnxruntime.version: project.onnxruntimeVersion

lib.sodium.enabled: project.useSodium
lib.sodium.version: project.sodiumVersion
//lib.sodium.dynamicLibraries: project.useSodium ? original : []

ProbExt.LibValidationProbe {
id: libValidationProbe
checkingLibs: [
lib.sodium
   ,lib.onnxruntime
]
}

cpp.defines: project.cppDefines
cpp.cxxFlags: project.cxxFlags
cpp.cxxLanguageVersion: project.cxxLanguageVersion

cpp.includePaths: [
"./",
"../",
project.buildDirectory,
]

cpp.systemIncludePaths: QbsUtl.concatPaths(
 Qt.core.cpp.includePaths // Декларация для подавления Qt warning-ов
,"/usr/include/python3.8"
,lib.sodium.includePath
,lib.onnxruntime.includePath
 )

cpp.rpaths: QbsUtl.concatPaths(
lib.sodium.libraryPath
   ,lib.onnxruntime.libraryPath
   ,"$ORIGIN/../lib"
)

cpp.libraryPaths: QbsUtl.concatPaths(
lib.sodium.libraryPath
   ,lib.onnxruntime.libraryPath
)

cpp.dynamicLibraries: QbsUtl.concatPaths(
"pthread"
   ,"python3.8"
   ,lib.sodium.dynamicLibraries
   ,lib.onnxruntime.dynamicLibraries
)

Group {
  name: "resources"
  files: [
  "processing.qrc",
  ]
}

Group {
name: "encription"
fileTags: "encription"
files: FileInfo.joinPaths(project.sourceDirectory, "python/*")
}
Group {
name: "encription2"
fileTags: "encription2"
files: "/var/opt/fns-processing/models/test-model.onnx"
}

Group {
fileTagsFilter: ["encript-resource"]
fileTags: ["qt.core.resource_data"]
Qt.core.resourcePrefix: "encription"
}
Group {
fileTagsFilter: ["encript-resource2"]
fileTags: ["qt.core.resource_data"]
Qt.core.resourcePrefix: "encription2"
}
//Qt.core.resourceFileBaseName: "encription"

files: [
"processing.cpp",
"processing_appl.cpp",
"processing_appl.h",
]

////--- Variant 1 ---
//Rule {
//id: idencript
//explicitlyDependsOnFromDependencies: ["appl-encryptor"]

//inputs: ["encription"]

//Artifact {
//fileTags: ["encript-resource"]
//filePath: FileInfo.joinPaths(project.buildDirectory,

Re: [Qbs] Dynamic generation of the resource file

2021-10-02 Thread Карелин Павел
Denis, if you can suggest how to generate a second resource file - I 
will only be glad.


Now I assume that the name of the dynamic resource file depends on the 
parameters

  Qt.core.resourceFileBaseName: "trigrams"
  Qt.core.resourcePrefix: "trigrams"

And I don't understand how to specify another file name.

--
Pavel

02.10.2021 09:17, Denis Shienkov пишет:


Hi,

> how to add another "qresource prefix" section to this resource file, 
for example "binary"?


But, for what? You can create/generate just a second resource file 
with the binaries.


BR, Denis

01.10.2021 22:47, Карелин Павел пишет:

Good time of day, colleagues

I previously asked how to dynamically create a resource file for 
project QGit (https://github.com/hkarel/qgit). The answer was 
received (see correspondence below).

I got the following solution:

    Group {
    name: "trigrams"
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "trigrams", input.baseName 
+ ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

As a result, such a resource file is created:



    
    alias="en_US.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/en_US.tmap
    alias="ru_RU.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/ru_RU.tmap

    


Question: how to add another "qresource prefix" section to this 
resource file, for example "binary"?

So that the resource file looks like this:



    
    alias="en_US.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/en_US.tmap
    alias="ru_RU.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/ru_RU.tmap

    
    
    alias="file1.bin">/home/hkarel/CProjects/QGit/build/Debug/binary_res/file1.bin
    alias="file2.bin">/home/hkarel/CProjects/QGit/build/Debug/binary_res/file1.bin

    


--
BR, Pavel



 Перенаправленное сообщение 
Тема: 	Re: [Qbs] Build and run a AuxiliaryApplication before build a 
MainApplication

Дата:   Mon, 22 Feb 2021 11:00:18 +0100
От: Christian Kandeler 
Кому:   qbs@qt-project.org



On 2/19/21 5:43 PM, Карелин Павел wrote:

Project QGit__micro is attached.
The situation is reproduced 


I've attached the corrected qbs files.



Christian



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


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


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


[Qbs] Dynamic generation of the resource file

2021-10-01 Thread Карелин Павел

Good time of day, colleagues

I previously asked how to dynamically create a resource file for project 
QGit (https://github.com/hkarel/qgit). The answer was received (see 
correspondence below).

I got the following solution:

    Group {
    name: "trigrams"
    fileTags: "trigrams"
    files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")

    }

    Group {
    fileTagsFilter: ["trigrams-map"]
    fileTags: ["qt.core.resource_data"]
    }
    Qt.core.resourceFileBaseName: "trigrams"
    Qt.core.resourcePrefix: "trigrams"

    Rule {
    id: idtrigrams
    inputs: ["trigrams"]
    explicitlyDependsOnFromDependencies: ["trigrams-generator"]

    Artifact {
    fileTags: ["trigrams-map"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap")

    }
    prepare: {
    var runUtl = 
explicitlyDependsOn["trigrams-generator"][0].filePath
    var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap");


    var cmd = new Command(runUtl, [input.filePath, outputFile]);
    cmd.description = "sonnet parse trigrams";
    cmd.highlight = "filegen";
    return cmd;
    }
    }

As a result, such a resource file is created:



    
    alias="en_US.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/en_US.tmap
    alias="ru_RU.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/ru_RU.tmap

    


Question: how to add another "qresource prefix" section to this resource 
file, for example "binary"?

So that the resource file looks like this:



    
    alias="en_US.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/en_US.tmap
    alias="ru_RU.tmap">/home/hkarel/CProjects/QGit/build/Debug/trigrams/ru_RU.tmap

    
    
    alias="file1.bin">/home/hkarel/CProjects/QGit/build/Debug/binary_res/file1.bin
    alias="file2.bin">/home/hkarel/CProjects/QGit/build/Debug/binary_res/file1.bin

    


--
BR, Pavel



 Перенаправленное сообщение 
Тема: 	Re: [Qbs] Build and run a AuxiliaryApplication before build a 
MainApplication

Дата:   Mon, 22 Feb 2021 11:00:18 +0100
От: Christian Kandeler 
Кому:   qbs@qt-project.org



On 2/19/21 5:43 PM, Карелин Павел wrote:

Project QGit__micro is attached.
The situation is reproduced 


I've attached the corrected qbs files.



Christian


import qbs
import qbs.File
import qbs.FileInfo

Product {
name: "QGit"
targetName: "qgit"

type: "application"
destinationDirectory: "./bin"

Depends { name: "cpp" }
Depends { name: "GenTrigrams" }
Depends { productTypes: ["trigrams-generator"] }
Depends { name: "Qt"; submodules: ["core", "widgets"] }

Group {
fileTags: "trigrams"
files: FileInfo.joinPaths(product.sourceDirectory, 
"spellcheck/sonnet/trigrams/*")
}

Group {
fileTagsFilter: ["trigrams-map"]
fileTags: ["qt.core.resource_data"]
}
Qt.core.resourceFileBaseName: "trigrams"
Qt.core.resourcePrefix: "trigrams"

Rule {
id: idtrigrams
inputs: ["trigrams"]
explicitlyDependsOnFromDependencies: ["trigrams-generator"]

Artifact {
fileTags: ["trigrams-map"]
filePath: FileInfo.joinPaths(project.buildDirectory, "trigrams", 
input.baseName + ".tmap")
}
prepare: {
var runUtl = explicitlyDependsOn["trigrams-generator"][0].filePath
var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"trigrams", input.baseName + ".tmap");

//console.info("=== runUtl ===");
//console.info(input);
//console.info(inputs);
//console.info(runUtl);
//console.info(input.filePath);
//console.info(outputFile);

var cmd = new Command(runUtl, [input.filePath, outputFile]);
cmd.description = "sonnet parse trigrams";
cmd.highlight = "filegen";
return cmd;
}
}

files: [
"qgit.cpp",
]

//property var test: {
//console.info("=== Qt.core.version ===");
//console.info(Qt.core.version);
//console.info("=== VERSION_PROJECT ===");
//console.info(project.projectVersion[0]);
//}
}
import qbs
import qbs.FileInfo

Product {
n

Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-15 Thread Карелин Павел

Made a minimum project (in attach). It turned out to start it.

A new question has appeared: the list of libraries in the product can be 
changed. See "lib.libmod.dynamicLibraries" in the product.qbs, line 13. 
The adjusted list will not be included in the rule. It can be fixed?


In passing, one more question: the libmod.qbs file does not appear in 
the project tree in QtC. Is it supposed to be like this?


--
Pavel


13.05.2022 10:07, Christian Kandeler пишет:

On 5/12/22 21:10, Карелин Павел wrote:
John, thanks for the tip. Unfortunately, this was not enough, the 
rule is still not called. Looks like something else is needed...

Christian, can I ask you for help on this issue?


Try to distill the project into a minimal, self-contained example. 
Ideally, you'll find the problem while doing that. If not, please post 
the result here.



Christian

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




QbsTest.tar.gz
Description: application/gzip
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-17 Thread Карелин Павел



17.05.2022 17:36, Christian Kandeler пишет:

On 5/15/22 19:27, Карелин Павел wrote:


A new question has appeared: the list of libraries in the product can be
changed. See "lib.libmod.dynamicLibraries" in the product.qbs, line 
13. The

adjusted list will not be included in the rule. It can be fixed?


That's because you access the dynamicLibraries property via the module 
id, which is a file-scope thing. Don't ever use ids, except for Probes.


Instead, access the property via the product variable: 
product.lib.modlib.dynamicLibraries.

Yes, it turned out to use the refined dynamicLibraries list.
Now it will be necessary to comprehend the whole decision.
Christian, Jochen, thank!



In passing, one more question: the libmod.qbs file does not appear in 
the

project tree in QtC.


It does, in the last tree branch, "Qbs files".

Note that in your attached project, qbssearchPaths is missing, so if 
that worked on your system, then the library might have been pulled in 
from somewhere else, such as a global search path.

The qbsSearchPaths parameter is present. See file project.qbs
In my work projects, the "Qbs files" section is present. And in this 
mini-project, for some reason, it is not. So I decided to pay attention 
to this.


--
Pavel




Christian

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


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


[Qbs] Build QtC with QBS. Modification of repository

2022-06-02 Thread Карелин Павел

Hello, developers!

I build QtC 7 with QBS. After building the project, file 
share/qtcreator/qml-type-descriptions/qbs-bundle.json is modified. Here 
is the diff:


diff --git a/share/qtcreator/qml-type-descriptions/qbs-bundle.json 
b/share/qtcreator/qml-type-descriptions/qbs-bundle.json

index 7f0c688691..9b2f233a4c 100644
--- a/share/qtcreator/qml-type-descriptions/qbs-bundle.json
+++ b/share/qtcreator/qml-type-descriptions/qbs-bundle.json
@@ -17,6 +17,7 @@
 "qbs.Environment",
 "qbs.File",
 "qbs.FileInfo",
+    "qbs.Host",
 "qbs.ModUtils",
 "qbs.PathTools",
 "qbs.PkgConfig",


It can be fixed?

--
Best regards,
Pavel Karelin
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] QBS for Ubuntu LTS releases and docker images

2022-06-02 Thread Карелин Павел

Hi, Alberto!

Thanks for the repository. When I will be deploy a new assembly stand, I 
will definitely use it.


It's too bad the core developers of QBS didn't do this sooner. Now the 
fresh compiled version of QBS can only be downloaded as an archive (and 
in my country even this cannot be done now).
Not that this was a problem for me, but as an indirect sign of the 
immaturity of the product, there is a place to be. Sometimes I hear such 
reproaches among my colleagues.


Alberto, will the repository work for ARM-platforms? Or only Amd/Intel?

--
Best regards,
Pavel Karelin


29.05.2022 22:01, Alberto Mardegan пишет:

Hi all!
  In case this is of interest to somebody else than me: I've recently 
updated my Ubuntu PPA containing QBS 1.22.1 for Ubuntu Xenial, Bionic, 
Focal and Jammy:


  https://launchpad.net/~mardy/+archive/ubuntu/qbs-on-lts

Except for Jammy, QBS is linked statically, without using the Qt 
provided by the distribution (which is too old).

Also, I have a few Docker images with Qt 5.15, QBS 1.22.1 and cmake:

  https://hub.docker.com/repository/docker/mardy/qt

(these can be used on Gitlab CI, for example).

Ciao,
  Alberto



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


Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-12 Thread Карелин Павел
John, thanks for the tip. Unfortunately, this was not enough, the rule 
is still not called. Looks like something else is needed...

Christian, can I ask you for help on this issue?

--
Pavel

12.05.2022 12:07, Jochen Ulrich пишет:


>> Did you remember to connect the "package-build-file" tag to your

>> product type? Either by making this tag the product type or via a

>> chain of rules.

> I didn't do it, because I don't understand how to do it.

So for example you could do this:

```

Product {
    name: "ToxPhone"

    type: [ /* maybe some other types here… */ "package-build-file" ]

    // …

```

This will cause your rule to be executed because the product 
“ToxPhone” requires it because it is of the type produced by your rule.


See also 
https://qbs.io/docs/qml-qbslanguageitems-rule/#rules-and-product-types


Best

Jochen

*Von: *Qbs  im Auftrag von Карелин Павел 


*Datum: *Dienstag, 10. Mai 2022 um 18:27
*An: *qbs@qt-project.org 
*Betreff: *Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22



10.05.2022 17:49, Christian Kandeler пишет:
>
> On 5/10/22 15:02, Карелин Павел wrote:
>>
>>
>> 05.05.2022 12:14, Christian Kandeler пишет:
>>> On 5/5/22 11:00, Карелин Павел wrote:
>>>>
>>>>
>>>> 05.05.2022 10:47, Christian Kandeler пишет:
>>>>> On 5/4/22 18:18, Карелин Павел wrote:
>>>>>> Christian, how would you solve my problem?
>>>>>> After the project is built, the deb-package is assembled. To
>>>>>> build the deb-package, you need a list of dependent libraries
>>>>>> (not all, only parts, system dependencies no required). For
>>>>>> example this list:
>>>>>>
>>>>>> /opt/ffmpeg/4.4/lib/libavutil.so*
>>>>>> /opt/ffmpeg/4.4/lib/libswscale.so*
>>>>>> /opt/ffmpeg/4.4/lib/libswresample.so*
>>>>>> /opt/opencv/4.5.5/lib/libopencv_core.so*
>>>>>> /opt/opencv/4.5.5/lib/libopencv_calib3d.so*
>>>>>> /opt/opencv/4.5.5/lib/libopencv_imgproc.so*
>>>>>>
>>>>>> I can get library paths and names of so-modules from dependencies:
>>>>>>
>>>>>> Depends { name: "lib.ffmpeg" }
>>>>>> Depends { name: "lib.opencv" }
>>>>>>
>>>>>> How can I create such a list and put it in the package_build_info
>>>>>> file? With the rules?
>>>>> lib.ffmpeg and lib.opencv are modules in your projects?
>>>> Yes, they are modules. I use my own QBS-extensions to include
>>>> third-party assembled libraries in my projects
>>>> (https://github.com/hkarel/QbsExt/tree/master/modules/lib).
>>>
>>> Then I think the correct way is to
>>>
>>>     - collect these libraries in a Group in the respective module
>>>
>>>     - mark them as target artifacts (see
>>> 
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)

>>>
>>>     - give them a suitable tag
>>>
>>>     - on the consuming side, create a rule whose
>>> inputsFromDependencies matches that tag and in this rule, do
>>> whatever you need to do.
>>
>> Tried to follow you recommendation:
>>
>> --- LibModule ---
>> Module {
>>     id: libmod
>>     property string prefix
>>     property string version: ""
>>
>>     property bool enabled: true
>>     property bool useSystem: false
>>
>>     property string includeSuffix: "/include"
>>     property string libSuffix: "/lib"
>>
>>     property path includePath: (useSystem || !enabled)
>>    ? undefined
>>    : prefix + (version.length ? "/" +
>> version : "") + includeSuffix
>>
>>     property path libraryPath: (useSystem || !enabled)
>>    ? undefined
>>    : prefix + (version.length ? "/" +
>> version : "") + libSuffix
>>
>>     property var dynamicLibraries: ["sodium"]
>>     property var staticLibraries: []
>>     ...
>>     Group {
>>     //name: "package-build"
>>     fileTags: "package-build"
>>     filesAreTargets: true
>>     files: {
>>     var libfiles = [];
>>     if (!libmod.useSystem && libmod.enabled)
>>     for (var i in libmod.dynamicLibraries) {
>>    

Re: [Qbs] QBS for Ubuntu LTS releases and docker images

2022-07-21 Thread Карелин Павел

Hi, Alberto.

Yesterday I installed the QBS from your repository on my ARM build stand.
Everything works great! Thanks for your work!

--
BR, Pavel

19.07.2022 14:54, Alberto Mardegan пишет:

Добрый день, Павел!

On 02/06/22 13:14, Карелин Павел wrote:
It's too bad the core developers of QBS didn't do this sooner. Now 
the fresh compiled version of QBS can only be downloaded as an 
archive (and in my country even this cannot be done now).


I happen to live in the same country :-)

Not that this was a problem for me, but as an indirect sign of the 
immaturity of the product, there is a place to be. Sometimes I hear 
such reproaches among my colleagues.


Alberto, will the repository work for ARM-platforms? Or only Amd/Intel?


The docker images are only AMD/Intel, but of course can be used to 
cross-compile if the right toolkit is provided.


The QBS builds on the Launchpad PPA are built for amd64, i386, armhf 
and arm64. So, given that the sources for the Docker images are public 
(see https://github.com/mardy/docker-images), I believe i should be 
easy to generate docker images for other architectures.


In my experience, however, cross compiling is always faster.

Ciao,
  Alberto
___
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] Failed build the project with QBS 1.22.1

2022-05-02 Thread Карелин Павел

I am using the construct:

Product {
    name: "SharedLib"

    property var exportIncludePaths: [
    "./",
    "./shared",
    ]

    Export {
    Depends { name: "cpp" }
    cpp.includePaths: product.exportIncludePaths
    }
}

I got this recipe here in the mailing list.. Perhaps this is your advice 
Christian (I don’t remember exactly now).

What construct should I use now? Like this?

    cpp.includePaths [
    "./",
    "./shared",
    ];

    Export {
    Depends { name: "cpp" }
    cpp.includePaths: [exportingProduct.cpp.includePaths]
    }

--
Pavel


02.05.2022 10:59, Christian Kandeler пишет:

On 4/29/22 17:27, Карелин Павел wrote:

[ ... ]
Now the compiler does not see the header file "shared/list.h" from 
the SharedLib dependency.

How to fix the problem?

You are likely using "product" in SharedLib's Export item where 
"exportingProduct" should be used.



Christian

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


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


Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-04 Thread Карелин Павел

> I cannot reproduce this.

I began to understand further and found out that the problem manifests 
itself in only one project. It turned out that at the project level I 
have a 'Probe' section:


Project {
    Probe {
    ...
    configure: {
    if (File.exists(projectBuildDirectory + "/package_build_info"))
    File.remove(projectBuildDirectory + "/package_build_info")
    }
    }
}

It turns out that when I opened the project in QtC, 'Probe' was executed 
from the 'PackageBuild' product (the package_build_info file was 
created), and when I started the build process, 'Probe' was executed 
from the project level (the package_build_info file was deleted). In 
versions QBS 1.21, 1.20, and earlier did not show this behavior.

My mistake, it's good to find it:))

> but I have a suspicion that a configure script is not the right place 
to do whatever it is you are doing there.
I agree, section 'Probe' is probably not very suitable for generating 
auxiliary files, but this is a very simple solution to my problem, which 
is why I used it.


Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build the 
deb-package, you need a list of dependent libraries (not all, only 
parts, system dependencies no required). For example this list:


/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*

I can get library paths and names of so-modules from dependencies:

Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }

How can I create such a list and put it in the package_build_info file? 
With the rules?


--
Pavel


04.05.2022 11:31, Christian Kandeler пишет:

On 5/3/22 21:44, Карелин Павел wrote:

Hello, developers.

I have a small product "PackageBuild" in my projects, I use it to 
generate the package_build_info file. 

[ ... ]
When I open the project in QtC 7 the file package_build_info is 
successfully created, but after the build process starts the file 
package_build_info is deleted.


I cannot reproduce this.

Note, however, that you should not keep untracked non-temporary files 
in the build directory. Generally, it should contain only proper 
artifacts created by rules. Of course I don't know the specifics of 
your project, but I have a suspicion that a configure script is not 
the right place to do whatever it is you are doing there.



Christian

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


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


[Qbs] Failed build the project with QBS 1.22.1

2022-04-29 Thread Карелин Павел

Hello, developers.

I have a QGit project (https://github.com/hkarel/qgit)
It builds fine with QBS 1.21.1 (gitrev: 36639ff3a)

Today I installed QBS 1.22.1 (gitrev: b6a46aa01) and the project stopped 
building.

I am getting this error:
ERROR: /usr/bin/g++ -O2 -Wall -Wextra -m64 -pipe -fexceptions 
-fvisibility=default -ggdb3 -Wall -Wextra -Wno-unused-parameter 
-Wno-variadic-macros -fPIC -DNDEBUG '-DVERSION_PROJECT="3.0.4"' 
-DVERSION_PROJECT_MAJOR=3 -DVERSION_PROJECT_MINOR=0 
-DVERSION_PROJECT_PATCH=4 '-DGIT_REVISION="6019056"' 
-DLOGGER_LESS_SNPRINTF '-DCONFIG_DIR="~/.config/qgit"' -DQT_CORE_LIB 
-DQT_NO_DEBUG 
-I/home/hkarel/CProjects/QGit/build/release-master/GenTrigrams.60541d6d/qt.headers 
-isystem/home/hkarel/CProjects/QGit/build/release-master/GenTrigrams.60541d6d/qt.headers 
-isystem/usr/include/x86_64-linux-gnu/qt5 
-isystem/usr/include/x86_64-linux-gnu/qt5/QtCore 
-isystem/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -std=c++17 -o 
/home/hkarel/CProjects/QGit/build/release-master/GenTrigrams.60541d6d/3a52ce780950d4d9/gentrigrams.cpp.o 
-c /home/hkarel/CProjects/QGit/src/spellcheck/sonnet/gentrigrams.cpp


ERROR: 
/home/hkarel/CProjects/QGit/src/spellcheck/sonnet/gentrigrams.cpp:11:10: 
fatal error: shared/list.h: No such file or directory

   11 | #include "shared/list.h"
  |  ^~~
compilation terminated.

Now the compiler does not see the header file "shared/list.h" from the 
SharedLib dependency.

How to fix the problem?

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


Re: [Qbs] Failed build the project with QBS 1.22.1

2022-05-03 Thread Карелин Павел



03.05.2022 11:39, Christian Kandeler пишет:

On 5/2/22 18:27, Карелин Павел wrote:

I am using the construct:

Product {
    name: "SharedLib"

    property var exportIncludePaths: [
    "./",
    "./shared",
    ]

    Export {
    Depends { name: "cpp" }
    cpp.includePaths: product.exportIncludePaths
    }
}


Just use this as-is, except with exportingProduct in the Export item.



Export {
    Depends { name: "cpp" }
    cpp.includePaths: [exportingProduct.cpp.includePaths]
    }


I'm not entirely sure, but this might use the merged value, 
potentially pulling in more paths than you want. Using a dedicated 
property seems cleaner.
The construct 'cpp.includePaths: [exportingProduct.cpp.includePaths]' 
does not work. QBS parsed it, but apparently the paths are not exported. 
The project is not built, the required header files are not found.

My old version works with replacing 'product' on 'exportingProduct':

   property var exportIncludePaths: [
    "./",
    "./shared",
    ]
    cpp.includePaths: exportIncludePaths

    Export {
    Depends { name: "cpp" }
    cpp.includePaths: exportingProduct.exportIncludePaths
    }

According to link https://codereview.qt-project.org/c/qbs/qbs/+/383049 
there was a change in the definition for variable 'product' inside the 
section 'Export'. Maybe then you need to display some message in the log 
about a change in behavior? I now have all the projects at work will 
fall down. People will come to me and say: "Your 'QBS' doesn't work" (I 
promote the use of QBS at my firm).
Can generally prohibit the use of variable 'product' in section 
'Export', lag behind only 'importingProduct' and 'exportingProduct'? 
Display a message about this in the log.






Christian

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


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


[Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-03 Thread Карелин Павел

Hello, developers.

I have a small product "PackageBuild" in my projects, I use it to 
generate the package_build_info file. The product code is shown below:


Product {
    name: "PackageBuild"

    Depends { name: "cpp" }
    Depends { name: "lib.sodium" }

    lib.sodium.version:   project.sodiumVersion
    lib.sodium.useSystem: project.useSystemSodium

    Probe {
    id: productProbe
    property string projectBuildDirectory: project.buildDirectory
  //property string cppstdlibPath: cppstdlib.path

    property var libs: [
    lib.sodium,
    ]

    configure: {
    var file = new TextFile(projectBuildDirectory + 
"/package_build_info", TextFile.WriteOnly);

    try {
    for (var n in libs) {
    var lib = libs[n];
    for (var i in lib.dynamicLibraries) {
    file.writeLine(lib.libraryPath + 
("/lib{0}.so*").format(lib.dynamicLibraries[i]));

    }
    }

    //if (!cppstdlibPath.startsWith("/usr/lib", 0)) {
    //    file.writeLine(cppstdlibPath + "/" + 
"libstdc++.so*");

    //    file.writeLine(cppstdlibPath + "/" + "libgcc_s.so*");
    //}
    }
    finally {
    file.close();
    }
    }
    }
}

When I open the project in QtC 7 the file package_build_info is 
successfully created, but after the build process starts the file 
package_build_info is deleted. How to make sure that file 
package_build_info is not deleted?


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


Re: [Qbs] Failed build the project with QBS 1.22.1

2022-05-03 Thread Карелин Павел



03.05.2022 18:15, Richard Weickelt пишет:

Hi,


My old version works with replacing 'product' on 'exportingProduct':

    property var exportIncludePaths: [
 "./",
 "./shared",
 ]
 cpp.includePaths: exportIncludePaths

 Export {
 Depends { name: "cpp" }
 cpp.includePaths: exportingProduct.exportIncludePaths
 }


I am not sure whether you have it working or not. Above pattern works 
on my end at least.


According to link 
https://codereview.qt-project.org/c/qbs/qbs/+/383049 there was a 
change in the definition for variable 'product' inside the section 
'Export'. Maybe then you need to display some message in the log 
about a change in behavior? 


It was a deliberate decision. The topic was first mentioned in:

https://code.qt.io/cgit/qbs/qbs.git/tree/changelogs/changes-1.18.0.md

The "product" variable in Export items was scheduled for removal in 
the 1.20 release. The re-introduction of "product", but now as an 
alias of "importingProduct" has been mentioned in:


https://code.qt.io/cgit/qbs/qbs.git/tree/changelogs/changes-1.22.0.md

I now have all the projects at work will fall down. People will come 
to me and say: "Your 'QBS' doesn't work" (I promote the use of QBS at 
my firm).
Can generally prohibit the use of variable 'product' in section 
'Export', lag behind only 'importingProduct' and 'exportingProduct'? 
Display a message about this in the log.


I am sorry to hear that this change creates inconvenience for you. 
What would you suggest to improve in case we have to do such a 
breaking change again?


Don't take critics of colleagues personally. You know the problem, you 
can help fixing the problem, everybody will be happy. People complain 
every day and have already forgotten about it the other day.
Yes, I think all projects will be fixed, everyone with assembly problems 
will come to me. I was probably just hurt that in a serious project, 
experienced developers allowed such a situation.
If in version 1.20/1.21 I saw a deprecated-message stating that 
'product' variable in section 'Export' is no longer supported and should 
be replaced with 'exportingProduct', then the problem would not have 
arisen. As I understood this transition did not happen spontaneously, 
you discussed it over several versions. I propose to display deprecate- 
messages in the future that QBS users could respond in a timely manner 
to impending changes.


--
BR, Pavel



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


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


Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22

2022-05-10 Thread Карелин Павел



05.05.2022 12:14, Christian Kandeler пишет:

On 5/5/22 11:00, Карелин Павел wrote:



05.05.2022 10:47, Christian Kandeler пишет:

On 5/4/22 18:18, Карелин Павел wrote:

Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build 
the deb-package, you need a list of dependent libraries (not all, 
only parts, system dependencies no required). For example this list:


/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*

I can get library paths and names of so-modules from dependencies:

Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }

How can I create such a list and put it in the package_build_info 
file? With the rules?

lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include 
third-party assembled libraries in my projects 
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).


Then I think the correct way is to

    - collect these libraries in a Group in the respective module

    - mark them as target artifacts (see 
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)


    - give them a suitable tag

    - on the consuming side, create a rule whose 
inputsFromDependencies matches that tag and in this rule, do whatever 
you need to do.


Tried to follow you recommendation:

--- LibModule ---
Module {
    id: libmod
    property string prefix
    property string version: ""

    property bool enabled: true
    property bool useSystem: false

    property string includeSuffix: "/include"
    property string libSuffix: "/lib"

    property path includePath: (useSystem || !enabled)
   ? undefined
   : prefix + (version.length ? "/" + 
version : "") + includeSuffix


    property path libraryPath: (useSystem || !enabled)
   ? undefined
   : prefix + (version.length ? "/" + 
version : "") + libSuffix


    property var dynamicLibraries: ["sodium"]
    property var staticLibraries: []
    ...
    Group {
    //name: "package-build"
    fileTags: "package-build"
    filesAreTargets: true
    files: {
    var libfiles = [];
    if (!libmod.useSystem && libmod.enabled)
    for (var i in libmod.dynamicLibraries) {
    libfiles.push(
    libmod.libraryPath +
("/lib{0}.so*").format(libmod.dynamicLibraries[i]))
    }

    console.info("=== libfiles ===");
    console.info(libfiles);

    return libfiles;
    }
    }
} // Module

LibModule {
    id: sodium
    version: "1.0.x"
    prefix: "/opt/sodium"
    checkingHeaders:  ["sodium.h"]
    dynamicLibraries: ["sodium"]
    staticLibraries:  ["sodium"]
}

Product {
    name: "ToxPhone"
    ...
    Depends { name: "lib.sodium" }
    ...
    lib.sodium.version:   project.sodiumVersion
    //lib.sodium.useSystem: project.useSystemSodium

    Rule {
    id: pkgbuild
    //inputs: ["package-build"]
    inputsFromDependencies: ["package-build"]

    Artifact {
    fileTags: ["package-build-file"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"package_build_info")

    }
    prepare: {
    var outputFile = FileInfo.joinPaths(project.buildDirectory, 
"package_build_info");


    console.info("=== outputFile ===");
    console.info(outputFile);
    }
    }

} // Product

The inscription "=== outputFile ===" is never printed. What am I doing 
wrong?





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] Failed 'PackageBuild' product on QBS 1.22

2022-05-10 Thread Карелин Павел



10.05.2022 17:49, Christian Kandeler пишет:


On 5/10/22 15:02, Карелин Павел wrote:



05.05.2022 12:14, Christian Kandeler пишет:

On 5/5/22 11:00, Карелин Павел wrote:



05.05.2022 10:47, Christian Kandeler пишет:

On 5/4/22 18:18, Карелин Павел wrote:

Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To 
build the deb-package, you need a list of dependent libraries 
(not all, only parts, system dependencies no required). For 
example this list:


/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*

I can get library paths and names of so-modules from dependencies:

Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }

How can I create such a list and put it in the package_build_info 
file? With the rules?

lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include 
third-party assembled libraries in my projects 
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).


Then I think the correct way is to

    - collect these libraries in a Group in the respective module

    - mark them as target artifacts (see 
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)


    - give them a suitable tag

    - on the consuming side, create a rule whose 
inputsFromDependencies matches that tag and in this rule, do 
whatever you need to do.


Tried to follow you recommendation:

--- LibModule ---
Module {
    id: libmod
    property string prefix
    property string version: ""

    property bool enabled: true
    property bool useSystem: false

    property string includeSuffix: "/include"
    property string libSuffix: "/lib"

    property path includePath: (useSystem || !enabled)
   ? undefined
   : prefix + (version.length ? "/" + 
version : "") + includeSuffix


    property path libraryPath: (useSystem || !enabled)
   ? undefined
   : prefix + (version.length ? "/" + 
version : "") + libSuffix


    property var dynamicLibraries: ["sodium"]
    property var staticLibraries: []
    ...
    Group {
    //name: "package-build"
    fileTags: "package-build"
    filesAreTargets: true
    files: {
    var libfiles = [];
    if (!libmod.useSystem && libmod.enabled)
    for (var i in libmod.dynamicLibraries) {
    libfiles.push(
    libmod.libraryPath +
("/lib{0}.so*").format(libmod.dynamicLibraries[i]))
    }

    console.info("=== libfiles ===");
    console.info(libfiles);

    return libfiles;
    }
    }
} // Module

LibModule {
    id: sodium
    version: "1.0.x"
    prefix: "/opt/sodium"
    checkingHeaders:  ["sodium.h"]
    dynamicLibraries: ["sodium"]
    staticLibraries:  ["sodium"]
}

Product {
    name: "ToxPhone"
    ...
    Depends { name: "lib.sodium" }
    ...
    lib.sodium.version:   project.sodiumVersion
    //lib.sodium.useSystem: project.useSystemSodium

    Rule {
    id: pkgbuild
    //inputs: ["package-build"]
    inputsFromDependencies: ["package-build"]

    Artifact {
    fileTags: ["package-build-file"]
    filePath: FileInfo.joinPaths(project.buildDirectory, 
"package_build_info")

    }
    prepare: {
    var outputFile = 
FileInfo.joinPaths(project.buildDirectory, "package_build_info");


    console.info("=== outputFile ===");
    console.info(outputFile);
    }
    }

} // Product

The inscription "=== outputFile ===" is never printed. What am I 
doing wrong?


Did you remember to connect the "package-build-file" tag to your 
product type? Either by making this tag the product type or via a 
chain of rules.

I didn't do it, because I don't understand how to do it.




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] Failed 'PackageBuild' product on QBS 1.22

2022-05-05 Thread Карелин Павел



05.05.2022 10:47, Christian Kandeler пишет:

On 5/4/22 18:18, Карелин Павел wrote:

Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build 
the deb-package, you need a list of dependent libraries (not all, 
only parts, system dependencies no required). For example this list:


/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*

I can get library paths and names of so-modules from dependencies:

Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }

How can I create such a list and put it in the package_build_info 
file? With the rules?

lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include 
third-party assembled libraries in my projects 
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).




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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-21 Thread Карелин Павел

I have a question: does anyone use QtC builded using QBS?
The fact is that in QtC 8, the QBS build system does not work. See 
picture in the attachment. The inscription in the red rectangle is 
"Failed to retrieve version."

The problem is in improperly spelled out path to QBS libraries.
I solved this problem through a crutch. Wrote the ld-path in the system: 
/opt/qtcreator/8.0/lib/qtcreator


--
BR, Pavel


21.10.2022 17:23, Christian Kandeler via Qbs пишет:

Hi,

we have released qbs 1.23.2 today.
As usual, sources, binaries, change log etc can be found here: 
https://download.qt.io/official_releases/qbs/1.23.2/

This release of qbs is also part of Qt Creator 8.0.2.


Christian

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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-24 Thread Карелин Павел



24.10.2022 13:48, Christian Kandeler via Qbs пишет:

On 10/24/22 12:34, Карелин Павел wrote:
I think runpath is wrong for libqbscore.so.1.23.2: instead of 
'$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator'



Why? bin/ and lib/ are located on the same level.
Because loading the libqbsscriptengine.so.1.23 library comes from 
libqbscore.so.1.23.2, not bin/qbs.
I conducted an experiment: in the libqbscore.so.1.23.2 I replaced 
runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' to 
'$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi'

And everything worked for me.

I think that if libqbsscriptengine.so.1.23 to link directly to qbs, then 
everything will work too. The only thing, the loading of 
libqbsscriptengine.so.1.23 should occur before loading libqbscore.so.1.23.2





Christian

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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-24 Thread Карелин Павел



24.10.2022 17:28, Christian Kandeler via Qbs пишет:

On 10/24/22 16:15, Карелин Павел wrote:



24.10.2022 16:58, Christian Kandeler via Qbs пишет:

On 10/24/22 15:38, Карелин Павел wrote:



24.10.2022 13:48, Christian Kandeler via Qbs пишет:

On 10/24/22 12:34, Карелин Павел wrote:
I think runpath is wrong for libqbscore.so.1.23.2: instead of 
'$ORIGIN/../lib/qtcreator' it should be 
'$ORIGIN/../../lib/qtcreator'



Why? bin/ and lib/ are located on the same level.
Because loading the libqbsscriptengine.so.1.23 library comes from 
libqbscore.so.1.23.2, not bin/qbs.
I conducted an experiment: in the libqbscore.so.1.23.2 I replaced 
runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' 
to '$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi'

And everything worked for me.

The problem seems to be differences in linker behavior. My binaries 
have RPATH set, yours use RUNPATH. The former works recursively, the 
latter doesn't. What linker are you using? I have binutils 2.39.

Systerm compiler from Ubuntu 20.04. GCC version 9.4.0

That doesn't answer the linker question.

binutils 2.34-6ubuntu1.3

In my qbs projects, I explicitly use RPATH instead of RUNPATH using 
the following command:



cpp.driverLinkerFlags: [
    "-Wl,--disable-new-dtags",
    ]


My man page says:

  By default, the new dynamic tags are not created.

In my man it says the same thing:

man ld
 --enable-new-dtags
 --disable-new-dtags
  This linker can create the new dynamic tags in ELF. But the 
older ELF systems may not understand them. If you specify 
--enable-new-dtags, the new dynamic tags will be created as needed and 
older dynamic tags will be omitted.  If you specify --disable-new-dtags, 
no new dynamic tags will be created. By default, the new dynamic tags 
are not created. Note that those options are only available for ELF systems.


But in fact, the default uses runpath. I ran into this problem when I 
switched to Ubuntu 20.04, and therefore began to use 
"-Wl,--disable-new-dtags".


I rebuild QtC8 with "-Wl,--disable-new-dtags". Now QtC/QBS works fine 
(the crutch is turned off, verified :)))


--
Pavel




Christian

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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-24 Thread Карелин Павел

Early I was happy, I forgot to remove my crutch from ld-paths.
My recipe corrected the problem of searching for dependence only for 
libqbscore.so.1.23.2

QBS inside QTC8 still does not work.


24.10.2022 16:38, Карелин Павел пишет:



24.10.2022 13:48, Christian Kandeler via Qbs пишет:

On 10/24/22 12:34, Карелин Павел wrote:
I think runpath is wrong for libqbscore.so.1.23.2: instead of 
'$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator'



Why? bin/ and lib/ are located on the same level.
Because loading the libqbsscriptengine.so.1.23 library comes from 
libqbscore.so.1.23.2, not bin/qbs.
I conducted an experiment: in the libqbscore.so.1.23.2 I replaced 
runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' to 
'$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi'

And everything worked for me.

I think that if libqbsscriptengine.so.1.23 to link directly to qbs, 
then everything will work too. The only thing, the loading of 
libqbsscriptengine.so.1.23 should occur before loading 
libqbscore.so.1.23.2





Christian

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



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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-24 Thread Карелин Павел



24.10.2022 16:58, Christian Kandeler via Qbs пишет:

On 10/24/22 15:38, Карелин Павел wrote:



24.10.2022 13:48, Christian Kandeler via Qbs пишет:

On 10/24/22 12:34, Карелин Павел wrote:
I think runpath is wrong for libqbscore.so.1.23.2: instead of 
'$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator'



Why? bin/ and lib/ are located on the same level.
Because loading the libqbsscriptengine.so.1.23 library comes from 
libqbscore.so.1.23.2, not bin/qbs.
I conducted an experiment: in the libqbscore.so.1.23.2 I replaced 
runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' to 
'$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi'

And everything worked for me.

The problem seems to be differences in linker behavior. My binaries 
have RPATH set, yours use RUNPATH. The former works recursively, the 
latter doesn't. What linker are you using? I have binutils 2.39.

Systerm compiler from Ubuntu 20.04. GCC version 9.4.0

In my qbs projects, I explicitly use RPATH instead of RUNPATH using the 
following command:

    cpp.driverLinkerFlags: [
    "-Wl,--disable-new-dtags",
    ]

This could be used in QBS assembly. The only thing, is that I probably 
will not quickly navigate which qbs-script is better to place this 
instruction. I will try.


--
Pavel





Christian

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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-26 Thread Карелин Павел

Christian, does it make sense to add construct

cpp.driverLinkerFlags: [
    "-Wl,--disable-new-dtags",
]

to the project code QBS?

Or is this problem on Ubuntu only I have?

On the other hand, the people on the internet writes that RUNPATH is a 
more correct approach (for example here: 
https://stackoverflow.com/questions/51952784/embed-rpath-instead-of-runpath-in-when-building-shared-objects-on-ubuntu-18-04)



What do you think about this?

--
Pavel

P.S.
When QBS is builded as an independent project (outside QtC), this case 
everything works even with RUNPATH. Although, perhaps there is some 
"magic" with paths. In my system directly states the path to 
standalone-QBS project (/etc/profile.d/qbs.sh => export 
PATH=$PATH:/opt/qbs/bin)



24.10.2022 19:16, Карелин Павел пишет:



24.10.2022 17:28, Christian Kandeler via Qbs пишет:

On 10/24/22 16:15, Карелин Павел wrote:



24.10.2022 16:58, Christian Kandeler via Qbs пишет:

On 10/24/22 15:38, Карелин Павел wrote:



24.10.2022 13:48, Christian Kandeler via Qbs пишет:

On 10/24/22 12:34, Карелин Павел wrote:
I think runpath is wrong for libqbscore.so.1.23.2: instead of 
'$ORIGIN/../lib/qtcreator' it should be 
'$ORIGIN/../../lib/qtcreator'



Why? bin/ and lib/ are located on the same level.
Because loading the libqbsscriptengine.so.1.23 library comes from 
libqbscore.so.1.23.2, not bin/qbs.
I conducted an experiment: in the libqbscore.so.1.23.2 I replaced 
runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' 
to '$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi'

And everything worked for me.

The problem seems to be differences in linker behavior. My binaries 
have RPATH set, yours use RUNPATH. The former works recursively, 
the latter doesn't. What linker are you using? I have binutils 2.39.

Systerm compiler from Ubuntu 20.04. GCC version 9.4.0

That doesn't answer the linker question.

binutils 2.34-6ubuntu1.3

In my qbs projects, I explicitly use RPATH instead of RUNPATH using 
the following command:



cpp.driverLinkerFlags: [
    "-Wl,--disable-new-dtags",
    ]


My man page says:

  By default, the new dynamic tags are not created.

In my man it says the same thing:

man ld
 --enable-new-dtags
 --disable-new-dtags
  This linker can create the new dynamic tags in ELF. But the 
older ELF systems may not understand them. If you specify 
--enable-new-dtags, the new dynamic tags will be created as needed and 
older dynamic tags will be omitted.  If you specify 
--disable-new-dtags, no new dynamic tags will be created. By default, 
the new dynamic tags are not created. Note that those options are only 
available for ELF systems.


But in fact, the default uses runpath. I ran into this problem when I 
switched to Ubuntu 20.04, and therefore began to use 
"-Wl,--disable-new-dtags".


I rebuild QtC8 with "-Wl,--disable-new-dtags". Now QtC/QBS works fine 
(the crutch is turned off, verified :)))


--
Pavel




Christian

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



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


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


Re: [Qbs] Qbs 1.23.2 released

2022-10-26 Thread Карелин Павел
> Do I understand correctly that you use self-built QtC and you built 
it using Qbs?

Yes. Moreover, Qbs is also self-built :))

> My understanding is that RUNPATH only affects libraries with a NEEDED 
entry, i.e. direct dependencies, while RPATH covers indirect 
dependencies as well.
Here says about the same: 
https://stackoverflow.com/questions/47117443/dynamic-linking-with-rpath-not-working-under-ubuntu-17-10/47243544#47243544


> What I don't understand is why Pavel's linker uses RUNPATH and mine 
uses RPATH by default. Could it be that distributions patch binutils 
according to their preferences?
This problem began to arise in people when switching to Ubuntu 18.04 (I 
ran into it at Ubuntu 20.04 because I missed 18.04)

Apparently in Canonical decided that RUNPATH by default is more right.

--
Pavel


26.10.2022 14:38, Christian Kandeler via Qbs пишет:

On 10/26/22 13:24, Иван Комиссаров wrote:

I think, both RPATH and RUNPATH should work.


My understanding is that RUNPATH only affects libraries with a NEEDED 
entry, i.e. direct dependencies, while RPATH covers indirect 
dependencies as well. What I don't understand is why Pavel's linker 
uses RUNPATH and mine uses RPATH by default. Could it be that 
distributions patch binutils according to their preferences?



Christian

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


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


[Qbs] RUNPATH problem in Ubuntu 20.04

2022-11-24 Thread Карелин Павел

Christian, hello.

Are there any plans to solve the problem of RUNPATH?
Or will everything remain as it is?

--
Pavel


26.10.2022 16:29, Карелин Павел пишет:
> Do I understand correctly that you use self-built QtC and you built 
it using Qbs?

Yes. Moreover, Qbs is also self-built :))

> My understanding is that RUNPATH only affects libraries with a 
NEEDED entry, i.e. direct dependencies, while RPATH covers indirect 
dependencies as well.
Here says about the same: 
https://stackoverflow.com/questions/47117443/dynamic-linking-with-rpath-not-working-under-ubuntu-17-10/47243544#47243544


> What I don't understand is why Pavel's linker uses RUNPATH and mine 
uses RPATH by default. Could it be that distributions patch binutils 
according to their preferences?
This problem began to arise in people when switching to Ubuntu 18.04 
(I ran into it at Ubuntu 20.04 because I missed 18.04)

Apparently in Canonical decided that RUNPATH by default is more right.

--
Pavel


26.10.2022 14:38, Christian Kandeler via Qbs пишет:

On 10/26/22 13:24, Иван Комиссаров wrote:

I think, both RPATH and RUNPATH should work.


My understanding is that RUNPATH only affects libraries with a NEEDED 
entry, i.e. direct dependencies, while RPATH covers indirect 
dependencies as well. What I don't understand is why Pavel's linker 
uses RUNPATH and mine uses RPATH by default. Could it be that 
distributions patch binutils according to their preferences?



Christian

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



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


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