Re: [Qbs] QBS usage

[Uwe Salomon]

Hello,

regarding the question of Tino Pyssyalo: we at Diehl Aerospace have switched
to Qbs in the research department for all new software projects.

Recently, we also moved a "legacy" project to Qbs which involved
project-specific build tools and multiple target architectures combined in a
single build (which we solved using make to trigger qbs multiple times; no
use of qbs multiplexing yet), as well as packaging for Debian.  Before, this
project used a non-recursive makefile-based build system, which had good
performance but grew a little difficult to maintain.

Main reasons for the switch to Qbs were:

* its good integration with Qt Creator: that the clang backend gives good
  autocompletion and warning/error "forecast" because it knows exactly how
  source files will be compiled (#defines, compiler switches etc), and the
  Qt Creator project file is identical to the build definition

* its scalability for larger projects

* its extendability: A tool (like a custom compiler) can define a Qbs module
  which can then be imported by other projects

Now that we progressively move to larger teams working with Qbs, I think the
most interesting issue will be how much every developer needs to know about
Qbs in order to participate in a project.  Using it involves quite some
learning effort, and it definitely does have its pitfalls.

Best regards,
Uwe


--
Uwe Salomon
Technical Project Manager

Diehl Aerospace
An der Sandelmuehle 13
60439 Frankfurt
Germany

Phone: +49 69 5805-1731
Email: uwe.salo...@diehl.com
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] QBS usage

[Christian Kandeler]

On Tue, 19 Jun 2018 14:37:54 +0300
NIkolai Marchenko  wrote:

> A custom toolchain module repository then, maybe? Something not necessairly
> 100% to the standard if qbs, but a place to gather templates people could
> start off of.
> I would gladly contribute my grpc/protobuf generator to such a place. it's
> not 100% ideal code, but it does its job even if it needs a bit of setting
> up.

If you want to make it public, why not just contribute it to the project? Rough 
edges can be straightened out on gerrit.


Christian 

> 
> 
> On Tue, Jun 19, 2018 at 10:52 AM, Christian Kandeler <
> christian.kande...@qt.io> wrote:  
> 
> > On Tue, 19 Jun 2018 14:15:44 +1200
> > Christian Gagneraud  wrote:
> >  
> > > On 18 June 2018 at 20:58, Christian Kandeler   
> > wrote:  
> > > > On Mon, 18 Jun 2018 11:01:10 +1200
> > > > Christian Gagneraud  wrote:
> > > >  
> > > >> Last thing, Qbs has built-in support for different compilers/linkers,
> > > >> this is nice b/c I can just express my toolchian flags in a toolchain
> > > >> agnostic way, but...
> > > >> - Qbs will have to continuously catch up with the fast moving  
> > toolchain world  
> > > >> - Users depend on Qbs core team to gain support for exotic compilers  
> > > >
> > > > How so? You can just provide your own cpp backend, if you wish. Or  
> > provide a patch to extend an existing one.  
> > >
> > > Sorry wrote the email in a rush, "Qbs core team" => Qbs developer. Of
> > > course qbs users can contribute, but users don't always have
> > > time/willing to dig into Qbs source code and hack it around.
> > > How can i provide my own backend? Do I have to write code, and build
> > > it against Qbs source tree? Or can it be provided via a local qbs
> > > file?  
> >
> > It's just a module. To provide support for a completely custom toolchain,
> > you'd create a cpp directory somewhere, possibly setting a search path so
> > that it is found, and put a module file in there with the necessary rules
> > and a condition that matches your toolchain.
> > In most cases, it's more likely that the new toolchain is somewhat related
> > to an existing one (typically gcc), so only minor tweaks would be needed.
> > In any case, the code you'll write is written in the same language as your
> > project files.
> >
> >
> > 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

[NIkolai Marchenko]

A custom toolchain module repository then, maybe? Something not necessairly
100% to the standard if qbs, but a place to gather templates people could
start off of.
I would gladly contribute my grpc/protobuf generator to such a place. it's
not 100% ideal code, but it does its job even if it needs a bit of setting
up.


On Tue, Jun 19, 2018 at 10:52 AM, Christian Kandeler <
christian.kande...@qt.io> wrote:

> On Tue, 19 Jun 2018 14:15:44 +1200
> Christian Gagneraud  wrote:
>
> > On 18 June 2018 at 20:58, Christian Kandeler 
> wrote:
> > > On Mon, 18 Jun 2018 11:01:10 +1200
> > > Christian Gagneraud  wrote:
> > >
> > >> Last thing, Qbs has built-in support for different compilers/linkers,
> > >> this is nice b/c I can just express my toolchian flags in a toolchain
> > >> agnostic way, but...
> > >> - Qbs will have to continuously catch up with the fast moving
> toolchain world
> > >> - Users depend on Qbs core team to gain support for exotic compilers
> > >
> > > How so? You can just provide your own cpp backend, if you wish. Or
> provide a patch to extend an existing one.
> >
> > Sorry wrote the email in a rush, "Qbs core team" => Qbs developer. Of
> > course qbs users can contribute, but users don't always have
> > time/willing to dig into Qbs source code and hack it around.
> > How can i provide my own backend? Do I have to write code, and build
> > it against Qbs source tree? Or can it be provided via a local qbs
> > file?
>
> It's just a module. To provide support for a completely custom toolchain,
> you'd create a cpp directory somewhere, possibly setting a search path so
> that it is found, and put a module file in there with the necessary rules
> and a condition that matches your toolchain.
> In most cases, it's more likely that the new toolchain is somewhat related
> to an existing one (typically gcc), so only minor tweaks would be needed.
> In any case, the code you'll write is written in the same language as your
> project files.
>
>
> 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

[Christian Kandeler]

On Tue, 19 Jun 2018 14:15:44 +1200
Christian Gagneraud  wrote:

> On 18 June 2018 at 20:58, Christian Kandeler  wrote:
> > On Mon, 18 Jun 2018 11:01:10 +1200
> > Christian Gagneraud  wrote:
> >  
> >> Last thing, Qbs has built-in support for different compilers/linkers,
> >> this is nice b/c I can just express my toolchian flags in a toolchain
> >> agnostic way, but...
> >> - Qbs will have to continuously catch up with the fast moving toolchain 
> >> world
> >> - Users depend on Qbs core team to gain support for exotic compilers  
> >
> > How so? You can just provide your own cpp backend, if you wish. Or provide 
> > a patch to extend an existing one.  
> 
> Sorry wrote the email in a rush, "Qbs core team" => Qbs developer. Of
> course qbs users can contribute, but users don't always have
> time/willing to dig into Qbs source code and hack it around.
> How can i provide my own backend? Do I have to write code, and build
> it against Qbs source tree? Or can it be provided via a local qbs
> file?

It's just a module. To provide support for a completely custom toolchain, you'd 
create a cpp directory somewhere, possibly setting a search path so that it is 
found, and put a module file in there with the necessary rules and a condition 
that matches your toolchain.
In most cases, it's more likely that the new toolchain is somewhat related to 
an existing one (typically gcc), so only minor tweaks would be needed. In any 
case, the code you'll write is written in the same language as your project 
files.


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

Re: [Qbs] QBS usage

[Christian Gagneraud]

On 18 June 2018 at 20:58, Christian Kandeler  wrote:
> On Mon, 18 Jun 2018 11:01:10 +1200
> Christian Gagneraud  wrote:
>
>> Last thing, Qbs has built-in support for different compilers/linkers,
>> this is nice b/c I can just express my toolchian flags in a toolchain
>> agnostic way, but...
>> - Qbs will have to continuously catch up with the fast moving toolchain world
>> - Users depend on Qbs core team to gain support for exotic compilers
>
> How so? You can just provide your own cpp backend, if you wish. Or provide a 
> patch to extend an existing one.

Sorry wrote the email in a rush, "Qbs core team" => Qbs developer. Of
course qbs users can contribute, but users don't always have
time/willing to dig into Qbs source code and hack it around.
How can i provide my own backend? Do I have to write code, and build
it against Qbs source tree? Or can it be provided via a local qbs
file?

Chris

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

Re: [Qbs] QBS usage

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

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

Re: [Qbs] QBS usage

[Richard Weickelt]

>> But I've had a hard time to sell Qbs at work for embedded C programming.
>> The major issues is that Qbs doesn't support awkward toolchains like IAR
>> or TI CGT.
>
> There is nothing magical about that. If you provide the necessary
> information, these can simply be supported by a new cpp backend.

Absolutely and by no means I wanted to blame you! I assume that "simply
adding a new cpp backend" would require a responsible maintainer and
continuous regression tests on that particular backend. The mentioned
toolchains are usually not used by hobby-ists and thus so I do not expect
anybody to invest their spare-time. At least, I won't.

Can anybody share a success story how he/she introduced Qbs in their
team/company? Is there anybody contributing to Qbs at work who is not
directly related to The QtCompany?

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

Re: [Qbs] QBS usage

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

Hi,

I am using QBS for small projects on my work and very happy with it. Other
developers works mostly with MSVC 2017, so generators
 are very important for us if we
will try to switch more projects to QBS.
Wish list:
* Woud be nice to be sure in QBS future (some clear plans from Qt Company
or knowing that some big company is using QBS and will support it if
anything).
* CMake generator. May be it sounds insane but it will be a killer-feature
and will help to integrate with exisiting  CMake-world.
* More how-to examples.

P.S. Thanks to all people behind QBS for your work!


On Sat, Jun 16, 2018 at 5:58 AM Tino Pyssysalo  wrote:

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


-- 
--
Best regards,
Aleksei Skorodumov
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] QBS usage

[Christian Kandeler]

On Mon, 18 Jun 2018 11:01:10 +1200
Christian Gagneraud  wrote:

> Last thing, Qbs has built-in support for different compilers/linkers,
> this is nice b/c I can just express my toolchian flags in a toolchain
> agnostic way, but...
> - Qbs will have to continuously catch up with the fast moving toolchain world
> - Users depend on Qbs core team to gain support for exotic compilers

How so? You can just provide your own cpp backend, if you wish. Or provide a 
patch to extend an existing one.


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

Re: [Qbs] QBS usage

[Christian Kandeler]

On Sun, 17 Jun 2018 10:43:03 +0200
Richard Weickelt  wrote:

> But I've had a hard time to sell Qbs at work for embedded C programming. The
> major issues is that Qbs doesn't support awkward toolchains like IAR or TI
> CGT. 

There is nothing magical about that. If you provide the necessary information, 
these can simply be supported by a new cpp backend. 


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

Re: [Qbs] QBS usage

[Christian Gagneraud]

On 16 June 2018 at 15:58, Tino Pyssysalo  wrote:
> I’d like to know, if you have used or are using QBS as a build system in
> real projects and all feedback and suggestions would be mostly welcome. This
> is a great opportunity to affect the future of QBS. Obviously, we are
> closely following QBS issues in Jira and in this mailing list, so there’s no
> need to report any known issues, unless you want to emphasize something
> extremely important to you.

I use it on pet projects, and tried to use it for at work (for my own
consumption) for a big C++/Qt project.

I really like Qbs, but i will try to focus on the dark areas, i guess
you want to hear these as well.

IMHO, the main show stopper for Qbs adoption is lack of support in the
most popular IDEs.
Visual Studio, Visual Code, XCode, Eclipse, ... are not Qbs aware.
The minimum needed would be that these tools at least understand how
to read it (to get list of  source, targets, ...), and how to fire
build, clean, run steps.
At work, most of the devs use Visual Studio, and there are on-going
discussions about switching to CMake, if only VS could handle Qbs...

I think Qbs is a great tool, I like the language and the modern design.
However, what i don't like:
- Too "elitist": cannot easily be used on projects with dodgy
dependencies, it seem to offer an all or nothing.
- toolchain and Qt profiles, are IMHO counter-intuitive. Qbs is the
only build tool i'm aware of that requires having "global" profiles.
  IMHO profiles should be managed at "configure time" of a project,
gcc and Qt profiles should be managed via probes?
- Command line interface could be simplified and be more end-user
friendly, as of now it still looks like a power-user tool
  I've always like the GNU autotools workflow (but not the underlying
technology!), eg I should be able to do:
  $ qbs configure --enable-foo --disable-bar --with-stuff=/usr/local/...
  $ qbs build
  $ qbs check
  $ qbs install DESTDIR=...
  $ qbs package

  The above functionalities can be done with qbs, but i think that it
should be as simple as the above commands, something straight forward.

Last thing, Qbs has built-in support for different compilers/linkers,
this is nice b/c I can just express my toolchian flags in a toolchain
agnostic way, but...
- Qbs will have to continuously catch up with the fast moving toolchain world
- Users depend on Qbs core team to gain support for exotic compilers
- You will never be able to unify them all, too much specificities,
corner cases, ...
- Other tools have different approaches, they let users have their own
boiler plate inside their projects.

It is a strength of Qbs, but somehow it could be a weakness at the same time.


Keep up the good job!
Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] QBS usage

[Timur Kristóf]

Hi Tino,

On Sat, 2018-06-16 at 03:58 +, Tino Pyssysalo wrote: 
> I’m Tino Pyssysalo, the new product owner of QBS at the Qt Company.

Congrats on your new role!

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

Cool! It's really nice to see that you are genuinely interested in your
users.
 
> I’d like to know, if you have used or are using QBS as a build system
> in real projects

Yes, I currently use it in an embedded project with the Qt Creator
"bare metal" plugin and the arm-none-eabi GCC toolchain.

Also tried to use it with other projects, but on each attempt there was
always an issue that kept us back.

>  and all feedback and suggestions would be mostly welcome. This is a
> great opportunity to affect the future of QBS.

If I recall correctly, one of the main pain points was support for 3rd
party libraries in a cross-platform way. One of my collegaues hit a
wall with this when he tried to switch his project to QBS.

I personally prefer QBS to qmake because it is more flexible and the
syntax is friendlier. Also the fact that it parallelizes builds by
default is great. I hope it will soon be adopted as the default
solution.

Thanks & best regards,
Tim

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

Re: [Qbs] QBS usage

[Richard Weickelt]

Hello Tino,

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

I was really worried when your handyman and chief evangelist jumped off the
boat towards the dark side in February. So I've got a question back: What
are the current plans of TQtC for Qbs? Any roadmap? I saw that there is
ongoing work to port Qt modules to Qbs.

> I’d like to know, if you have used or are using QBS as a build system in
> real projects and all feedback and suggestions would be mostly welcome. This
> is a great opportunity to affect the future of QBS. Obviously, we are
> closely following QBS issues in Jira and in this mailing list, so there’s no
> need to report any known issues, unless you want to emphasize something
> extremely important to you.
I have been using it in pet projects, Qt and non-Qt. Especially in the
latter case I am very glad to get away from GNU make and CMake. The
easy-to-rehearse markup language, clean concept and especially separation of
profiles and project files beats any other build system I have seen. Qbs has
also helped me a lot to structure my projects better. It's really
easy-to-use once you understood the concept and the concept feels like
coming from the textbook.

But I've had a hard time to sell Qbs at work for embedded C programming. The
major issues is that Qbs doesn't support awkward toolchains like IAR or TI
CGT. The other issue is a general scepticism about anything else than GNU
Make or GUI-based build systems in IAR, Eclipse, etc. But I don't know how
to address the latter.

I see room for improvement in the QtCreator integration. Maintaining
profiles with custom settings and inheritance is still painful. I would
rather vote for keeping profiles in QML rather than config files + GUI.
Since QML profiles are nowadays possible in projects, I wonder if that could
be applied to normal profiles as well. https://bugreports.qt.io/browse/QBS-895

Now I can't wait for using Qbs for development of Qt. QMake sucks and
incrementally rebuilding a Qt Module takes forever.

Richard



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

Re: [Qbs] QBS usage

[Ben Lau]

Hello Tino,

I only use Qbs in a pet project. I wish it could support running external
commands / scripts easily. Something similar to the `run` command in npm.

Reference:
https://docs.npmjs.com/cli/run-script

Example Use-cases:
- Deploy the built binary to somewhere
- Start mock server
- Fetch test case from somewhere before running the tests




On Sat, 16 Jun 2018 at 11:58, Tino Pyssysalo  wrote:

> 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

Re: [Qbs] QBS usage

[NIkolai Marchenko]

Hi there! Been extensively using QBS both at work and for my own project. I
really like how easy it was to integrate grpc/protobuf generation module in
the build process.
It also makes much more sense overall than qmake. Mostly the thing is
great, but the manual could really use some love.

About the only thing laicking in qbs is an extensive tutorial (not
manual/reference) with best usage practices.
It's kinda hard to sell it to people who arent as bilingual as I am when
they have to google a lot in english to solve their issues.

I meet quite a lot of scepticism here and reluctance to move from qmake,
but ppl who's actually worked with it on the projects (usually a joint
project with me initially, lol) like it.


On Sat, Jun 16, 2018 at 6:58 AM, Tino Pyssysalo 
wrote:

> 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

Re: [Qbs] QBS usage

[Dmitry Volosnykh]

Hi, Tino!

At the moment I find myself using QBS extensively for my pet projects. But
I feel confidence in its quality level and find it closer to ready for
production.

Regarding projects I have been involved in for the last several years the
only missing features that serve as a show stoppers are the lack of support
for generation of CMake exported targets (see QBS-1233) and for building
Deb packages (see QBS-417). Once these two features are implemented I am
really happy to strongly consider moving production projects to be powered
by QBS.
On Sat, 16 Jun 2018 at 06:58, Tino Pyssysalo  wrote:

> 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] QBS usage

[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