Re: [Qbs] External Dependencies

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

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

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

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

Re: [Qbs] External Dependencies

[NIkolai Marchenko]

Unfortunately I still don't see how or where the chain of dependencies on
DarwinGCC and GenericGCC  is being set up. Will it be in zlib module ?
I am trying to understand how will the application know what is the
"recovery" option and when to consider all recovery paths exhausted and
can't bc I do not see any external linking between those in the examples
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] External Dependencies

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

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

And we have UnixGCC.qbs:

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

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

I suggest adding something like

DarwinGCC {
recover: true
}

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

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

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

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


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

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

Re: [Qbs] External Dependencies

[NIkolai Marchenko]

> by adding property bool recover to the Module which tells Qbs to try loading 
> next module in a chain

Probably needs a code example of a proposed solution. What is a
"chain" like in this case?


On Tue, May 14, 2019 at 11:32 PM Иван Комиссаров  wrote:

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

Re: [Qbs] External Dependencies

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

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

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

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

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

products.MyProduct.pkgconfig.condition:false

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

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

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

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

Re: [Qbs] External Dependencies

[NIkolai Marchenko]

And while we are on the subject of finding libs. Is it possible to somehow
indicate that a library you are trying to link isn't compatible with the
compiler? Somethe _other_ than "unresolved external" error that can
indicate anything from lib not being where you want it to be, a mistype in
the path, incorrect lib version or, indeed, binary incompatibility. .

On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko 
wrote:

> Wouldn't it be more reasonable to implement something like OptionalDepends
> where you could just list all possible dependencies in the order in which
> it should be loaded?
>
> On Tue, May 14, 2019 at 9:26 PM Иван Комиссаров  wrote:
>
>> I would like to discuss the way how external dependencies should be
>> searched by qbs.
>>
>> While implementing support for the protobuf I found that there several
>> place where a generic c++ can come from.
>>
>> 1. It can be detected via pkg-config
>> 2. It can be detected using probes
>> 3. Other pkg-config-like tools? Maybe Vcpkg?
>> 4. It can be the part of the project.
>>
>> I am not sure if we need to support 4, but if the mechanism of library
>> searching will be based on the Depends item, I don’t see why user can’t add
>> a «zlib» product that will be fetched prior to system modules. But anyway,
>> that’s not the point.
>>
>> The point is that for now, I have to write stuff like
>>
>> Depends {
>>
>> name: "internal.libprotobuf.pkgconfig"
>>
>> condition: _autoDetect
>>
>> required: false
>>
>> }
>>
>> Depends {
>>
>> name: "internal.libprotobuf.probes"
>>
>> condition: _autoDetect && !internal.libprotobuf.pkgconfig.found
>>
>> required: false
>>
>> }
>>
>>
>> Note, that libprotobuf.pkgconfig and libprotobuf.probes are *different* 
>> modules
>> in different folders under qbs/modules.
>> In case I want to add third way to fetch a library, I will require third
>> module and third Depends item. Too much boilerplate for a modern build
>> system.
>>
>> This comes from the limitation that modules are loaded only based on
>> their condition and priority and it is not possible to use Probes in
>> conditions. I guess, this limitation comes from the fact that probes are
>> heavy to evaluate, but I’m not sure.
>> Either that limitation should be removed, or we can extend the way Qbs
>> loads modules by adding property bool recover to the Module which tells
>> Qbs to try loading next module in a chain (with lower priority) if loading
>> «best suitable» module failed. If the property is false by default, current
>> behavior will be preserved and we can use it to implement «chain» loading
>> by simply writing Depends { name: "internal.libprotobuf" }.
>>
>> Next thing I want to discuss is the way how Qbs should search for
>> libraries using Probes. For now, we have IncludeProbe, LibraryProbe and
>> FrameworkProbe (for macOS frameworks). It is not very convenient to use
>> them directly, but we can wrap them into a ExternalPackage module that
>> provides some input properties to tell Probes what to search for:
>>
>> ExternalPackage {
>>
>> name: "zlib"
>>
>> headers: ["zlib.h"]
>>
>> libraryNames: ["z"]
>>
>> }
>>
>>
>> We can also provide some properties to tell Qbs where to search for
>> libraries or to override some default behavior:
>>
>> qbs build modules.ExternalPackage.platformSearchPaths:"/opt/usr/lib"
>> modules.ExternalPackage.staticLibs:true
>>
>> That way, we will have mechanism similar to CMake find package module and
>> we can provide support for lot of libraries in a *declarative* way.
>>
>> Any thoughts?
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> https://lists.qt-project.org/listinfo/qbs
>>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] External Dependencies

[NIkolai Marchenko]

Wouldn't it be more reasonable to implement something like OptionalDepends
where you could just list all possible dependencies in the order in which
it should be loaded?

On Tue, May 14, 2019 at 9:26 PM Иван Комиссаров  wrote:

> I would like to discuss the way how external dependencies should be
> searched by qbs.
>
> While implementing support for the protobuf I found that there several
> place where a generic c++ can come from.
>
> 1. It can be detected via pkg-config
> 2. It can be detected using probes
> 3. Other pkg-config-like tools? Maybe Vcpkg?
> 4. It can be the part of the project.
>
> I am not sure if we need to support 4, but if the mechanism of library
> searching will be based on the Depends item, I don’t see why user can’t add
> a «zlib» product that will be fetched prior to system modules. But anyway,
> that’s not the point.
>
> The point is that for now, I have to write stuff like
>
> Depends {
>
> name: "internal.libprotobuf.pkgconfig"
>
> condition: _autoDetect
>
> required: false
>
> }
>
> Depends {
>
> name: "internal.libprotobuf.probes"
>
> condition: _autoDetect && !internal.libprotobuf.pkgconfig.found
>
> required: false
>
> }
>
>
> Note, that libprotobuf.pkgconfig and libprotobuf.probes are *different* 
> modules
> in different folders under qbs/modules.
> In case I want to add third way to fetch a library, I will require third
> module and third Depends item. Too much boilerplate for a modern build
> system.
>
> This comes from the limitation that modules are loaded only based on their
> condition and priority and it is not possible to use Probes in conditions.
> I guess, this limitation comes from the fact that probes are heavy to
> evaluate, but I’m not sure.
> Either that limitation should be removed, or we can extend the way Qbs
> loads modules by adding property bool recover to the Module which tells
> Qbs to try loading next module in a chain (with lower priority) if loading
> «best suitable» module failed. If the property is false by default, current
> behavior will be preserved and we can use it to implement «chain» loading
> by simply writing Depends { name: "internal.libprotobuf" }.
>
> Next thing I want to discuss is the way how Qbs should search for
> libraries using Probes. For now, we have IncludeProbe, LibraryProbe and
> FrameworkProbe (for macOS frameworks). It is not very convenient to use
> them directly, but we can wrap them into a ExternalPackage module that
> provides some input properties to tell Probes what to search for:
>
> ExternalPackage {
>
> name: "zlib"
>
> headers: ["zlib.h"]
>
> libraryNames: ["z"]
>
> }
>
>
> We can also provide some properties to tell Qbs where to search for
> libraries or to override some default behavior:
>
> qbs build modules.ExternalPackage.platformSearchPaths:"/opt/usr/lib"
> modules.ExternalPackage.staticLibs:true
>
> That way, we will have mechanism similar to CMake find package module and
> we can provide support for lot of libraries in a *declarative* way.
>
> Any thoughts?
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[André Pönitz]

On Tue, May 14, 2019 at 08:42:50PM +0200, Richard Weickelt wrote:
> Tobias,
> 
> I think it is of utmost importance for the survival of Qbs that it is
> fully supported by an IDE like QtCreator.
> 
> > Note that this is about the build system used to *build Qt Creator
> > with*, not about *build systems supported by Qt Creator*. I would
> > personally like to keep qbs supported as a build system for projects
> > in Qt Creator for as long as it is feasible.
> 
> What would yo define as the minimum criteria for keeping Qbs supported
> in Qt Creator?
> 
> > The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs
> > is linked into Creator, that will also need to be ported to Qt 6 to
> > stay feasible.
> 
> Do you already have an idea when QtCreator will switch to Qt 6? Given
> the current release plan https://wiki.qt.io/Qt5Releasing, I expect the
> first release of Qt6 to happen around November 2020.

It surely won't be before that. 

For Qt4->Qt5 we kept the code compilable with both for more than
a year, already to have a test bed for Qt4->Qt5 regressions.

I'd like to try the same for 5->6.

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Richard Weickelt]

Tobias,

I think it is of utmost importance for the survival of Qbs that it is fully
supported by an IDE like QtCreator.

> Note that this is about the build system used to *build Qt Creator with*, not
> about *build systems supported by Qt Creator*. I would personally like to keep
> qbs supported as a build system for projects in Qt Creator for as long as it 
> is
> feasible.

What would yo define as the minimum criteria for keeping Qbs supported in Qt
Creator?

> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is linked
> into Creator, that will also need to be ported to Qt 6 to stay feasible.

Do you already have an idea when QtCreator will switch to Qt 6? Given the
current release plan https://wiki.qt.io/Qt5Releasing, I expect the first
release of Qt6 to happen around November 2020.

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

[Qbs] External Dependencies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Vincent Hui]

Another issue is that Qt Creator will not ship with Qt Script if Qt Script
will be dropped in Qt 6. Don't know whether Qt Creator team is willing to
ship a forked Qt Script library.

Vincent


On Tue, 14 May 2019 at 19:51, Christian Gagneraud  wrote:

> On Tue, 14 May 2019 at 23:10, Joerg Bornemann 
> wrote:
> >
> > On 5/14/19 12:04 PM, Christian Gagneraud wrote:
> > > On Tue, 14 May 2019 at 22:02, Joerg Bornemann 
> wrote:
> > >>
> > >> On 5/14/19 10:57 AM, Tobias Hunger wrote:
> > >>
> > >>> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs
> is linked
> > >>> into Creator, that will also need to be ported to Qt 6 to stay
> feasible.
> > >>
> > >> ...which shouldn't pose a challenge at all given that Qt 6 is to keep
> > >> source incompatible changes minimal.
> > >
> > > Unless they drop QtScript...
> >
> > This is bound to happen anyway. It can be forked.
>
> But can it be maintained? Can it be ported to Qt6?
> By 'can', i mean who will do that? Who has the time, the resources?
>
> Chris
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

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

[Christian Gagneraud]

On Tue, 14 May 2019 at 23:35, Christian Gagneraud  wrote:
>
> On Tue, 14 May 2019 at 23:11, Christian Gagneraud  wrote:
> >
> > On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
> > >
> > > I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
> > > qtdeclarative originally used v8 JavaScript engine which got replaced 
> > > with Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's 
> > > possible to go the opposite direction and remove Qt dependency in the 
> > > first place?
> > > Except for GUI and script module, I don't think there's a lot of Qt stuff.
> >
> > chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
> > '*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
> > | sort | uniq -c | sort -nr
> >673 QtCore
> >  76 QtScript
> >   7 QtGui
> >   6 QtWidgets
> >   5 QtNetwork
> >   1 QtXml
>
> The above is the number of #include in all cpp and h files, per Qt
> module. As you can see dependency on QtCore is quite heavy.
>
> And here is the number of cpp/h files using QtScript, per directory:
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
> QtScript src/ | egrep '.(cpp|h)' | xargs dirname | sort | uniq -c |
> sort -nr
>  17 src/lib/corelib/buildgraph
>  14 src/lib/corelib/jsextensions
>  12 src/lib/corelib/language
>   3 src/lib/corelib/tools
>
> Ideally you would like to see only jsextensions and language

Just in case someone follows my monologue... :)

QtSCript dependency of buildgraph:
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -h
QtScript src/lib/corelib/buildgraph/ | sed -ne 's,^ *# *include
*]*\)>.*$,\1,gp' | sort | uniq -c | sort -nr
10 qscriptvalue.h
  3 qscriptengine.h
  3 qscriptcontext.h
  2 qscriptvalueiterator.h
  2 qscriptclass.h
  1 qscriptstring.h
  1 qscriptprogram.h
  1 qscriptclasspropertyiterator.h

I'm no expert at QtScript and Javascript, but this looks mostly like
"core" classes (value, engine, context, program).

And here are the "offenders"
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
QtScript src/lib/corelib/buildgraph/
src/lib/corelib/buildgraph/artifactsscriptvalue.cpp
src/lib/corelib/buildgraph/artifactsscriptvalue.h
src/lib/corelib/buildgraph/buildgraph.cpp
src/lib/corelib/buildgraph/buildgraph.h
src/lib/corelib/buildgraph/dependencyparametersscriptvalue.h
src/lib/corelib/buildgraph/depscanner.cpp
src/lib/corelib/buildgraph/depscanner.h
src/lib/corelib/buildgraph/processcommandexecutor.cpp
src/lib/corelib/buildgraph/projectbuilddata.h
src/lib/corelib/buildgraph/qtmocscanner.cpp
src/lib/corelib/buildgraph/qtmocscanner.h
src/lib/corelib/buildgraph/rulecommands.cpp
src/lib/corelib/buildgraph/rulecommands.h
src/lib/corelib/buildgraph/rulesapplicator.cpp
src/lib/corelib/buildgraph/rulesapplicator.h
src/lib/corelib/buildgraph/rulesevaluationcontext.h
src/lib/corelib/buildgraph/scriptclasspropertyiterator.h

But this is without looking at leaks from langugage itself:
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
QtScript src/lib/corelib/language/*.h
src/lib/corelib/language/evaluationdata.h
src/lib/corelib/language/evaluator.h
src/lib/corelib/language/evaluatorscriptclass.h
src/lib/corelib/language/language.h
src/lib/corelib/language/scriptengine.h
src/lib/corelib/language/scriptimporter.h

Is it worth the effort to remove QtScript from buildgraph and make
language hermetic to QtScript?
Versus: forking, maintaining (and improving?) QtScript.

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Christian Gagneraud]

On Tue, 14 May 2019 at 23:10, Joerg Bornemann  wrote:
>
> On 5/14/19 12:04 PM, Christian Gagneraud wrote:
> > On Tue, 14 May 2019 at 22:02, Joerg Bornemann  wrote:
> >>
> >> On 5/14/19 10:57 AM, Tobias Hunger wrote:
> >>
> >>> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is 
> >>> linked
> >>> into Creator, that will also need to be ported to Qt 6 to stay feasible.
> >>
> >> ...which shouldn't pose a challenge at all given that Qt 6 is to keep
> >> source incompatible changes minimal.
> >
> > Unless they drop QtScript...
>
> This is bound to happen anyway. It can be forked.

But can it be maintained? Can it be ported to Qt6?
By 'can', i mean who will do that? Who has the time, the resources?

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

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

[Christian Gagneraud]

On Tue, 14 May 2019 at 23:11, Christian Gagneraud  wrote:
>
> On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
> >
> > I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
> > qtdeclarative originally used v8 JavaScript engine which got replaced with 
> > Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible 
> > to go the opposite direction and remove Qt dependency in the first place?
> > Except for GUI and script module, I don't think there's a lot of Qt stuff.
>
> chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
> '*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
> | sort | uniq -c | sort -nr
>673 QtCore
>  76 QtScript
>   7 QtGui
>   6 QtWidgets
>   5 QtNetwork
>   1 QtXml

The above is the number of #include in all cpp and h files, per Qt
module. As you can see dependency on QtCore is quite heavy.

And here is the number of cpp/h files using QtScript, per directory:
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ git grep -l
QtScript src/ | egrep '.(cpp|h)' | xargs dirname | sort | uniq -c |
sort -nr
 17 src/lib/corelib/buildgraph
 14 src/lib/corelib/jsextensions
 12 src/lib/corelib/language
  3 src/lib/corelib/tools

Ideally you would like to see only jsextensions and language

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

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

[Christian Gagneraud]

On Tue, 14 May 2019 at 22:51, Иван Комиссаров  wrote:
>
> I wonder how hard is to implement pure c++ "declarative" library. Afaik, 
> qtdeclarative originally used v8 JavaScript engine which got replaced with 
> Qt-ish engine to avoid conversions to/from Qt types. Maybe, it's possible to 
> go the opposite direction and remove Qt dependency in the first place?
> Except for GUI and script module, I don't think there's a lot of Qt stuff.

chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^/>.]*\)[/>].*$,\1,gp'
| sort | uniq -c | sort -nr
   673 QtCore
 76 QtScript
  7 QtGui
  6 QtWidgets
  5 QtNetwork
  1 QtXml
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | xargs sed -ne 's, *# *include *<\(Q[^>]*\)>.*$,\1,gp' |
sort | uniq -c | sort -nr
 70 QtCore/qstring.h
 67 QtCore/qstringlist.h
 54 QtCore/qdir.h
 40 QtCore/qfileinfo.h
 39 QtCore/qvariant.h
 37 QtCore/qhash.h
 30 QtCore/qprocess.h
 28 QtCore/qshareddata.h
 28 QtCore/qobject.h
 26 QtScript/qscriptvalue.h
 25 QtCore/qlist.h
 25 QtCore/qcoreapplication.h
 24 QtCore/qfile.h
 20 QtScript/qscriptengine.h
 20 QtCore/qglobal.h
 18 QtCore/qmap.h
 17 QtCore/qdebug.h
 14 QtCore/qbytearray.h
 13 QtCore/qtimer.h
 12 QtCore/qtextstream.h
 11 QtCore/qregexp.h
 11 QtCore/qdiriterator.h
 10 QtScript/qscriptable.h
  8 QtCore/qt_windows.h
  7 QtCore/quuid.h
  7 QtCore/qdatastream.h
  6 QtCore/qsettings.h
  5 QtScript/qscriptvalueiterator.h
  5 QtScript/qscriptclass.h
  5 QtCore/qtemporaryfile.h
  4 QtScript/qscriptcontext.h
  4 QtCore/qthread.h
  4 QtCore/qloggingcategory.h
  4 QtCore/qcryptographichash.h
  3 QtCore/qmetatype.h
  3 QtCore/qjsonobject.h
  3 QtCore/qjsondocument.h
  3 QtCore/qflags.h
  3 QtCore/qdatetime.h
  2 QtScript/qscriptstring.h
  2 QtScript/qscriptprogram.h
  2 QtScript/qscriptclasspropertyiterator.h
  2 QtNetwork/qlocalsocket.h
  2 QtGui/qtextcursor.h
  2 QtCore/qxmlstream.h
  2 QtCore/qvarlengtharray.h
  2 QtCore/qlibrary.h
  2 QtCore/qjsonarray.h
  2 QtCore/qeventloop.h
  2 QtCore/qelapsedtimer.h
  2 QtCore/qabstractitemmodel.h
  1 QtXml/qdom.h
  1 QtWidgets/qmessagebox.h
  1 QtWidgets/qmenu.h
  1 QtWidgets/qmenubar.h
  1 QtWidgets/qmainwindow.h
  1 QtWidgets/qapplication.h
  1 QtWidgets/qaction.h
  1 QtNetwork/qsslcertificate.h
  1 QtNetwork/qsslcertificateextension.h
  1 QtNetwork/qlocalserver.h
  1 QtGui/qtextobject.h
  1 QtGui/qtextdocument.h
  1 QtGui/qkeysequence.h
  1 QtGui/qevent.h
  1 QtGui/qbrush.h
  1 QtCore/qvector.h
  1 QtCore/qurl.h
  1 QtCore/qtextcodec.h
  1 QtCore/qtemporarydir.h
  1 QtCore/qregularexpression.h
  1 QtCore/qpoint.h
  1 QtCore/qpair.h
  1 QtCore/qnumeric.h
  1 QtCore/qlockfile.h
  1 QtCore/qiodevice.h
  1 QtCore/qendian.h
  1 QtCore/qcommandlineparser.h
  1 QtCore/qcommandlineoption.h
  1 QtCore/qbytearraymatcher.h
  1 QtCore/qbytearraylist.h
  1 QtCore/private/qcore_mac_p.h
chgans@chgans-pc:~/Projects/qt-creator/src/shared/qbs$ find src/ -name
'*.[hc]*' | wc -l
482

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Joerg Bornemann]

On 5/14/19 12:04 PM, Christian Gagneraud wrote:
> On Tue, 14 May 2019 at 22:02, Joerg Bornemann  wrote:
>>
>> On 5/14/19 10:57 AM, Tobias Hunger wrote:
>>
>>> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is 
>>> linked
>>> into Creator, that will also need to be ported to Qt 6 to stay feasible.
>>
>> ...which shouldn't pose a challenge at all given that Qt 6 is to keep
>> source incompatible changes minimal.
> 
> Unless they drop QtScript...

This is bound to happen anyway. It can be forked.


BR,

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

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

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

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

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

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

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

[Richard Weickelt]

>> However, will this help to get new developers? Right now, there are not that
>> many contributors.
> 
> I agree, how much money do you want to raise? And what for?
> For now Qbs can use Qt (company/project) infra, so there's no need to
> manage an infra.

The Qt Company pays for qt.io. We can ask them to sponsor the domain also in 
the future, but we cannot expect it.

If we had fee-lancing contributors, then it might make sense to set up a bounty 
system. I also find models like this https://www.patreon.com/bjorn interesting. 
I guess that spare-time contributors have a different motivation though.

What is IMO more important is, to turn qbs.io into an attractive landing page. 
It should become more clear, that Qbs is no longer a The Qt Company project. 
Might be worth to pay a web designer to come up with a professional looking.  
Any volunteers? https://bugreports.qt.io/browse/QBS-1341

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

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

[Richard Weickelt]

> If I am right, one urgent task is to remove the dependency of Qt Script.

I don't think it's urgent. It might not even be necessary given that Qbs won't 
be Qt's next build system and won't have to be bootstrapped. But if you have 
good ideas, feel free to discuss in https://bugreports.qt.io/browse/QBS-913

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

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

[Vincent Hui]

If I am right, one urgent task is to remove the dependency of Qt Script.

Vincent


On Tue, 14 May 2019 at 17:51, Christian Gagneraud  wrote:

> On Tue, 14 May 2019 at 21:46, Иван Комиссаров  wrote:
> >
> > +1
> >
> > However, will this help to get new developers? Right now, there are not
> that many contributors.
>
> I agree, how much money do you want to raise? And what for?
> For now Qbs can use Qt (company/project) infra, so there's no need to
> manage an infra.
>
> Chris
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Christian Gagneraud]

On Tue, 14 May 2019 at 22:02, Joerg Bornemann  wrote:
>
> On 5/14/19 10:57 AM, Tobias Hunger wrote:
>
> > The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is 
> > linked
> > into Creator, that will also need to be ported to Qt 6 to stay feasible.
>
> ...which shouldn't pose a challenge at all given that Qt 6 is to keep
> source incompatible changes minimal.

Unless they drop QtScript...

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Joerg Bornemann]

On 5/14/19 10:57 AM, Tobias Hunger wrote:

> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is linked
> into Creator, that will also need to be ported to Qt 6 to stay feasible.

...which shouldn't pose a challenge at all given that Qt 6 is to keep 
source incompatible changes minimal.


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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

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

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

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

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

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

[Christian Gagneraud]

On Tue, 14 May 2019 at 21:46, Иван Комиссаров  wrote:
>
> +1
>
> However, will this help to get new developers? Right now, there are not that 
> many contributors.

I agree, how much money do you want to raise? And what for?
For now Qbs can use Qt (company/project) infra, so there's no need to
manage an infra.

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

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

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

+1

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

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

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Denis Shienkov]

14.05.2019 12:32, Tobias Hunger пишет:

There is no find_package script for qbs that we can just use.

Don't panic, it will be there.


In that case, you need to add possibility to build the QBS with CMake... 
No? :)


Or, how are you going to solve this?

BR,

Denis


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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Christian Gagneraud]

On Tue, 14 May 2019 at 21:32, Tobias Hunger  wrote:
>
> On Tue, 2019-05-14 at 21:06 +1200, Christian Gagneraud wrote:
> > From the change description:
> > All plugins have been converted to CMake, with the following exceptions:
> >   - qbsprojectmanager
> >
> > Any reason why?
>
> There is no find_package script for qbs that we can just use.
>
> Don't panic, it will be there.

phew! ;)

Are you planning to remove qbs as a submodule?
That's very handy when you work on QtC/Qbs integration

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Tobias Hunger]

On Tue, 2019-05-14 at 21:06 +1200, Christian Gagneraud wrote:
> From the change description:
> All plugins have been converted to CMake, with the following exceptions:
>   - qbsprojectmanager
> 
> Any reason why?

There is no find_package script for qbs that we can just use.

Don't panic, it will be there.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

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

[Карелин Павел]

+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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Christian Gagneraud]

On Tue, 14 May 2019 at 20:58, Tobias Hunger  wrote:
>
> On Tue, 2019-05-14 at 10:04 +0200, Ola Røer Thorsen wrote:
> > I'd like to know if Qt Creator will phase out Qbs support completely,
> > seeing the comments and summary in that commit ("Qbs is dead"). Would be
> > really bad for at least my team, if they did.
>
> That "qbs is dead" was me, so I guess I need to clarify that statement:

Quote:
Qbs is dead, I won't bother collecting that data:-) When I benchmarked
qbs against cmake they were in the same ballpark though

I will run a comparison, that is an interesting piece of information.

> I do not see qbs as an option to build Qt Creator with going forward. My plan 
> is
> to built creator with cmake and to remove both the qbs as well as the qmake
> build systems from the Qt Creator sources.
>
> Note that this is about the build system used to *build Qt Creator with*, not
> about *build systems supported by Qt Creator*. I would personally like to keep
> qbs supported as a build system for projects in Qt Creator for as long as it 
> is
> feasible.

From the change description:
All plugins have been converted to CMake, with the following exceptions:
  - qbsprojectmanager

Any reason why?

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Tobias Hunger]

On Tue, 2019-05-14 at 10:04 +0200, Ola Røer Thorsen wrote:
> I'd like to know if Qt Creator will phase out Qbs support completely,
> seeing the comments and summary in that commit ("Qbs is dead"). Would be
> really bad for at least my team, if they did.

That "qbs is dead" was me, so I guess I need to clarify that statement:

I do not see qbs as an option to build Qt Creator with going forward. My plan is
to built creator with cmake and to remove both the qbs as well as the qmake
build systems from the Qt Creator sources.

Note that this is about the build system used to *build Qt Creator with*, not
about *build systems supported by Qt Creator*. I would personally like to keep
qbs supported as a build system for projects in Qt Creator for as long as it is
feasible.

The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is linked
into Creator, that will also need to be ported to Qt 6 to stay feasible.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Donation to QBS developers/maintainers/contributes

[Алексей Скородумов]

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Ola Røer Thorsen]

tir. 14. mai 2019 kl. 10:12 skrev Vincent Hui :

> We can see Qbs development is active.
> https://github.com/qbs/qbs/commits/master?before=ca4987ae21f3cb30fde699448abc213b37b90214+35
> Therefore I don't think it is dead.
>
>
Sure I agree, however if the mindset elsewhere is that "Qbs is dead", they
won't even look into the Qbs changelogs no matter how active it is.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Vincent Hui]

We can see Qbs development is active.
https://github.com/qbs/qbs/commits/master?before=ca4987ae21f3cb30fde699448abc213b37b90214+35
Therefore I don't think it is dead.


On Tue, 14 May 2019 at 16:09, Pier Luigi Fiorini <
pierluigi.fior...@gmail.com> wrote:

> Il giorno mar 14 mag 2019 alle ore 10:04 Ola Røer Thorsen <
> o...@silentwings.no> ha scritto:
>
>>
>> tir. 14. mai 2019 kl. 09:45 skrev Vincent Hui :
>>
>>> Hi,
>>>
>>> Qt Creator was ported to CMake
>>> . It is interesting to
>>> compare build times of Qt Creator with CMake and Qbs.
>>>
>>> Did anyone benchmark qbs against cmake?
>>>
>>>
>> I'd like to know if Qt Creator will phase out Qbs support completely,
>> seeing the comments and summary in that commit ("Qbs is dead"). Would be
>> really bad for at least my team, if they did.
>>
>
> This comes as a surprise.
>
> I thought Qbs was neither dead nor obsolete, it was just transitioning
> from The Qt Company to the community.
>
> --
> https://liri.io
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Pier Luigi Fiorini]

Il giorno mar 14 mag 2019 alle ore 10:04 Ola Røer Thorsen <
o...@silentwings.no> ha scritto:

>
> tir. 14. mai 2019 kl. 09:45 skrev Vincent Hui :
>
>> Hi,
>>
>> Qt Creator was ported to CMake
>> . It is interesting to
>> compare build times of Qt Creator with CMake and Qbs.
>>
>> Did anyone benchmark qbs against cmake?
>>
>>
> I'd like to know if Qt Creator will phase out Qbs support completely,
> seeing the comments and summary in that commit ("Qbs is dead"). Would be
> really bad for at least my team, if they did.
>

This comes as a surprise.

I thought Qbs was neither dead nor obsolete, it was just transitioning from
The Qt Company to the community.

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Ola Røer Thorsen]

tir. 14. mai 2019 kl. 09:45 skrev Vincent Hui :

> Hi,
>
> Qt Creator was ported to CMake
> . It is interesting to
> compare build times of Qt Creator with CMake and Qbs.
>
> Did anyone benchmark qbs against cmake?
>
>
I'd like to know if Qt Creator will phase out Qbs support completely,
seeing the comments and summary in that commit ("Qbs is dead"). Would be
really bad for at least my team, if they did.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Vincent Hui]

Hi,

Qt Creator was ported to CMake
. It is interesting to
compare build times of Qt Creator with CMake and Qbs.

Did anyone benchmark qbs against cmake?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs