Re: [Development] Changes to Qt offering

[Christian Gagneraud]

On Thu, 30 Jan 2020 at 13:01, Oswald Buddenhagen
 wrote:
>
> On Wed, Jan 29, 2020 at 11:40:46PM +0100, Filippo Cucchetto wrote:
> >Maybe you didn't get it but i meant to both put a reasonable price for
> >a commercial license (500$) and turning everything GPL or commercial.
> >Making everything GPL forces all LGPL to buy a commercial license. This
> >obviously could turn away some people but only if there isn't a proper
> >offer for the commercial license.
> >
> that's a fine plan and i assure you that tqtc management would *love* to
> do at least the gpl part (not sure they'd have the wisdom to lower the
> prices and properly reward contributors, though).
>
> unfortunately, this won't work unless kde agrees that the only moral
> thing to do would be allowing tqtc to restore the pre-nokia gpl
> licensing, given that tqtc is in pretty much the same position as
> trolltech was. of course, tqtc has a much less likable and trustworthy
> management, but in their defense, they are also a bit desperate to
> satisfy their greedy shareholders. capitalism rocks, huh?
>
> (going gpl-only would inevitably lead to a fork, but if we assume
> appropriate licensing cost of upstream, that fork would be driven by
> people who are unable or unwilling to invest (time or money), plus a few
> idealists. that would make it pretty much an LTS branch, and thus not
> pose a serious threat to tqtc's business. at least that's my hypothesis.

10 years ago or so, I was working for a small (tiny) company, I wanted
to use Qt for a new project.
Back in these days, Qt was GPL only, and as i was doing proprietary
SW, I had to reject that idea.
Buying a license was a no-go (for whatever reason, this was not my business).
So I ended up reinvented the wheel (thread, network, byte/text processing, ...).

I would see Qt-GPL-only as a regression. I understand that tqtc needs
to make money, no problem with that.
But I'm not convinced that GPL-only will actually work as intended
(bring more user/money) as illustrated above.

My 2 cents,
Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Christian Gagneraud]

On Tue, 28 Jan 2020, 20:50 Thiago Macieira, 
wrote:

> On Monday, 27 January 2020 22:37:47 PST Benjamin TERRIER wrote:
> > You might have missed the info because it is in the blog post, but not in
> > Lars email:
> >
> > There will be no more open source offline installer.
>
> Thanks, I stand corrected.
>

And that's really bad news How many wget will get broken?
This cannot be true, Lars, tell me that download.qt.io will still work w/o
login/password. Please!



> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supported compilers for Qt 6

[Christian Gagneraud]

On Mon, 12 Aug 2019, 22:13 Thiago Macieira, 
wrote:

> On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> > The milestone is std::byte, which which we could put QByteArray on a
> > sound basis. And char8_t, which would make QUtf8String(View) fly.
>
> QByteArray, due to its dual string / byte array nature, will continue to
> operate on char. After all, char *is* a byte. We should add the unsigned
> char
> variants too, though.
>

What is a byte? An 8 bits unsigned integer, 0-255.
Char is unsigned on Intel arch, but is signed on arm.

Maybe it's time to get rid of qbytearray and qstring and qstringview, ...
And fully embrace (and contribute, like boost does, to)  modern c++.

My 2 cents


> As for char8_t, it's C++20. We're not going to enforce compiling Qt with
> -std=c++2a.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supported compilers for Qt 6

[Christian Gagneraud]

On Mon, 12 Aug 2019, 21:37 Thiago Macieira, 
wrote:

> On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
> > distributions and Android SDKs use.
>
> Any word on what Clang the Android SDK we'll require uses?
>

Clang 8 AFAIK, and let's not forget about their push of libc++ (Vs gnu
libstdc++)
As well, clang 9 went RC very recently.

Chris




> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt PDF as a new TP module for Qt 5.14

[Christian Gagneraud]

On Mon, 12 Aug 2019, 20:23 Konstantin Tokarev,  wrote:

>
>
> 12.08.2019, 21:01, "Thiago Macieira" :
> > On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
> >>  I guess bigger problem is that Poppler is GPL. PDFium is probably the
> only
> >>  permissively licensed PDF engine.
> >
> > And? If Poppler is a superior alternative, then people can accept its GPL
> > requirements or not display PDF.
>
> s/not display PDF/use alternative solution like pdf.js/
>

Haven't tried, but I doubt this in an acceptable solution on embedded
devices.

Chris


> fixed
>
> --
> Regards,
> Konstantin
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit very slow?

[Christian Gagneraud]

Hi there,

Is it just me or code-review.qt-project.org is very slow?
I have no problem with other web sites, but code-review keeps timing out?
Anyone else has the same problem?

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 20:24, Kevin Kofler  wrote:
>
> Christian Gagneraud wrote:
> > Please elaborate:https://gcc.gnu.org/install/configure.html
> >
> > Just from the top of the document:
> > --with-pkgversion
> > --with-bugurl
> > ...
> > --enable-shared
> > --enable-multiarch
> > ...
> >
> > Your argumentation is ill-formed.
>
> Of course there are examples where it is clear cut (but as Thiago pointed
> out, many projects get it wrong even in such cases). But see your earlier
> --with-pcre example: typically, building with PCRE support also enables some
> feature that depends on it. This is the case for many such switches in
> practice.
>
> And your --with-pkgversion and --with-bugurl cases show another use of
> --with that is completely unrelated to the external dependencies: passing
> some non-boolean value to the configure script. In CMake, those would just
> be, e.g.: -DBUG_URL:STRING=…

Basically your argumentation is: I'm right, they are all wrong. Only
CMake can save us all.

No very convincing.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 13:16, Kevin Kofler  wrote:
>
> Christian Gagneraud wrote:
> > with/without tells the system to use a thing or not.
> > enable/disable tells the system to enable/disable the thing feature.
>
> The problem is that typical build options are actually both at the same
> time: using a library enables some feature that depends on the library. So
> the semantic distinction is ill-defined.

Please elaborate:https://gcc.gnu.org/install/configure.html

Just from the top of the document:
--with-pkgversion
--with-bugurl
...
--enable-shared
--enable-multiarch
...

Your argumentation is ill-formed.

Chris

>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 11:16, Kevin Kofler  wrote:
>
> Konstantin Tokarev wrote:
> > Autotools provide human-readable options of standardized format
> >
> > --with-thing
> > --without-thing
> > --enable-thing
> > --disable-thing
>
> That's already 2 different standards for essentially the same thing (a
> boolean option),

This doesn't make sense to me, the underlying type has nothing to do
with the intent.

with/without tells the system to use a thing or not.
enable/disable tells the system to enable/disable the thing feature.

eg. --with-pcre --enable-expensive-operations

That is 2 different things even if they can be both expressed as boolean.

> and most non-GNU projects (and even some GNU ones) use them
> pretty arbitrarily and inconsistently. (There is supposed to be a semantic
> difference, but it is often arguable, because often a dependency and a
> feature go together. And several upstreams just use the 2 variants
> interchangeably altogether.)

And so what? Now you're gonna tell us that using CMake makes you smarter?
By switching to CMake you won't do the mistakes you did with another
build system?

With CMake i can arbitrarily and inconsistently use any convention.

>
> In CMake, there's just:
> -DTHING:BOOL=ON
> -DTHING:BOOL=OFF
> (and it also happily accepts a bunch of other notations for ON/OFF, without
> the CMakeLists.txt having to do anything).

So:
-DWITH_THING:BOOL=ON
-DWITH_THING:BOOL=OFF
-DENABLE_THING:BOOL=ON
-DENABLE_THING:BOOL=OFF

No difference except it's not very friendly to type.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 00:27, Christian Gagneraud  wrote:
>
> On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
>  wrote:
> >
> > > The world is not spinning around Qt, sorry for the bad news.
> >
> > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > I mean, I had actual CMake classes with a CMake exam on paper 6 years ago 
> > at the university -- you get a few hundreds of new devs on the job market 
> > every year out of that one, who *will* know CMake, and won't know qmake / 
> > qbs / [...].
>
> Are you insulting this mailing list?
> How do you think we made it so far without cmake? Honestly?
>
> The very fact you're discussing qmake and qbs just show that you know
> about them, and that you know what they provide cmake cannot provide
> (yet).
>
> > > I prefer a transparent self-bootstrapped Qt over an explicit two stages 
> > > one.
> > I (entirely personnally) really do not, - this is anecdotally one of the 
> > main objections I've heard about Qt (3k questions just about Qt's configure 
> > in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just 
> > answering to a standard cmake && make && make install which comes with gui 
> > discoverability through cmake-gui, embeddability through add_subdirectory 
> > or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead 
> > acting like its own microcosm library where you have to learn yet another 
> > set of commands & invocations if you want to integrate it in your existing 
> > system.
>
> Woah, you're ass is so shinny i can't see the light.

Hi Jean-Michaël,
I would like to apologise about that one, frustration got me in.
That wasn't smart from me, I do respect everyone, even when I disagree
with them.
I didn't mean to insult you, please forgive me, that was a stupid behaviour.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
 wrote:
>
> > The world is not spinning around Qt, sorry for the bad news.
>
> On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> I mean, I had actual CMake classes with a CMake exam on paper 6 years ago at 
> the university -- you get a few hundreds of new devs on the job market every 
> year out of that one, who *will* know CMake, and won't know qmake / qbs / 
> [...].

Are you insulting this mailing list?
How do you think we made it so far without cmake? Honestly?

The very fact you're discussing qmake and qbs just show that you know
about them, and that you know what they provide cmake cannot provide
(yet).

> > I prefer a transparent self-bootstrapped Qt over an explicit two stages one.
> I (entirely personnally) really do not, - this is anecdotally one of the main 
> objections I've heard about Qt (3k questions just about Qt's configure in SO 
> ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just answering 
> to a standard cmake && make && make install which comes with gui 
> discoverability through cmake-gui, embeddability through add_subdirectory or 
> C++ package managers such as conan, vcpkg, hunter, etc etc. but instead 
> acting like its own microcosm library where you have to learn yet another set 
> of commands & invocations if you want to integrate it in your existing system.

Woah, you're ass is so shinny i can't see the light.

> > Last comment: Please think about [...] Cmake is not yet ready for that.
>
> > embedded Linux
> Oh come on.

Yes, come on, why do i have to define a custom "toolchain file" each
time someone fart?
Can't you just understand the good old gnu configure triplet? Or the
concept of sytem/user wide profile? (qbs profile, qmake specs)
Why does every single project has to provide it's own set of CMake
toolchain files?
Have you ever thought about the problem?

Well, i doubt that. "If it works on my Windows machine, then it works
everywhere", right? (provocative sarcasm really)

> > qnx
> you mean like software companies using Qt do, today ? 
> https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake

I'm gob-smacked!!!
This is awesome.

They can use gcc to build a QNX app... Thanks CMake to allow QNX to
exists... This real-time kernel could never have existed without the
help of CMake.
My first experience with QNX, was.. at least 20 years ago. I'm not
even sure CMake existed back at that time.
But hey, you're revolutionizing the world, i cannot fight obviously...

> > vxworx
>
> VxWorks ships with CMake so there must be at least some amount of support. 
> (https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/?ncc=1_download=1)

Lol, did you run out of google searches? Honestly i can throw random
links too. Did you click "I'm felling lucky" or what?

> > iOS
>
> ... yes ? https://github.com/sheldonth/ios-cmake

Yeah right, problem solved then! Ship it! Come on, let's do it!

Let's make an announcement:

CMAKE FULLY SUPPORT IOS.

PS: well, not exactly, please carrefully read the small prints.

> Also, just because CMake now has acquired *official* support for iOS does not 
> mean that it hasn't been working for a long time. There were people shipping 
> iOS apps with CMake five years ago - and this is due in part to CMake having 
> a *large* community, unlike qmake / qbs, which means that even if CMake does 
> not directly support $FEATURE, chances are that you can find an 
> aptly-licensed open-source library that you can use to augment your build 
> with and achieve what you want.
> See e.g. all the projects that ship today with 
> https://github.com/leetal/ios-cmake, https://github.com/ruslo/polly, etc etc
> In contrast, how many people are shipping qmake extensions outside of QtCore, 
> as a library for anyone to use ?
>
> > android and whatever next os is coming.
> Oh come on (bis). CMake has been one of the official android build systems 
> for close to two years now : https://developer.android.com/ndk/guides/cmake
>
> Also, C++Builder was able to ship and advertise CMake support for Android & 
> iOS a year ago so there is no reason Qt cannot do the same : 
> https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android
>
> > and whatever next os is coming.
>
> you mean like Fuschia 
> (https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake) 
> or maybe actual operating systems built with CMake, such as IncludeOS 
> (https://github.com/includeos/IncludeOS) or ReactOS 
> (https://github.com/reactos/reactos) ? :-)

Man, your google skills outpace me to such an extent that i cannot be
bothered wasted more time...

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Mon, 17 Jun 2019, 21:13 Konstantin Tokarev,  wrote:

>
>
> 17.06.2019, 12:07, "Christian Gagneraud" :
> > On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
> >> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud <
> chg...@gmail.com>:
> >>>
> >>> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
> wrote:
> >>>>
> >>>> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> >>>> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> >>>> > > You can download a CMake static binary (
> https://cmake.org/download/) that
> >>>> >
> >>>> > (...)
> >>>> >
> >>>> > I would prefer that our requirements be present in Linux
> distributions we
> >>>> > declare are supported build environments. If nothing else, our CI
> will
> >>>> > benefit from this.
> >>>>
> >>>> Let's not pull CI into it. It already
> >>>
> >>>
> >>> Wow! Let's not pull in the system which only goal is to validate the
> "supported platforms" promise, is it what you mean?
> >>> If I need a special cmake to build Qt, then this should be shipped as
> part of Qt itself, another third-party source tree.
> >>> And then it means that I will need to build qt's build system. In
> other words, I'll have to bootstrap Qt build system.
> >>> I thought that it was a big no-no. The main argument to ditch qmake
> and qbs...
> >>
> >> Hm, what is the problem with using the official CMake binaries? Isn't
> >> that what you'd do on Windows / macOS anyway?
> >
> > In case you didn't follow the thread, building Qt with cmake requires a
> non-released version of cmake.
> >
> > The question is:
> > By the time qt6 will be out, will the requirement of cmake minimum
> version be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)
> >
> > The answer is that, best case, this is doable if qt6 is not released
> before 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the
> minimum req. is not bumped, which is very unlikely given the lack of
> support for Android, iOS, etc...)
> >
> >> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
> >> when it arrives, then great. But having to install the build tool from
> >> the vendor instead of the distro package manager surely can't be a
> >> blocker
> >
> > Really? Then convince the boot2qt team to force yocto to use the latest
> bleeding edge cmake version for their stable branch...
> > Good luck with that.
> >
> > And then, which is my point, you're asking your customers to
> build/install Qt build system in order to build Qt itself.
> > That is wrong. The world is not spinning around Qt, sorry for the bad
> news.
> > I prefer a transparent self-bootstrapped Qt over an explicit two stages
> one.
> >
> > Right now the cmake build system doesn't respect the initial
> requirements that were used to ditch contenders.
> >
> > This is in no way a democratic process.
>
> Democracy has no power here.
>
> "The Qt Project is a _meritocratic_, consensus-based community interested
> in Qt."
>
> Decisions are up to tho who does the work.
>


And those who throw money at it: QtC customers.




> > This is selective hearing, reqs for cmake are artificially lowered while
> reqs for contenders are artificially raised.
> >
> > I have no doubt that cmake will be Qt6 build system, this is your
> choice, I'm just asking to stop this simulation, and I'm asking you to take
> your responsibilities, if building Qt6 is not supported on mainstream
> platforms I might consider switching away from Qt.
> >
> > Last comment: Please think about embedded Linux, qnx, vxworx, iOS,
> android and whatever next os is coming.
> > Cmake is not yet ready for that.
> >
> > Chris
> >
> >> Elvis
> >>
> >>>
> >>> Chris
> >>>
> >>>
> >>>> covers installation of the cmake in
> >>>> order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
> >>>> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
> >>>>
> >>>> Cheers,
> >>>>   Jędrek
> >>>>
> >>>>
> >>>> ___
> >>>> Development mailing list
> >>>> Development@qt-project.org
> >>>> https://lists.qt-project.org/listinfo/development
> >>>
> >>> ___
> >>> Development mailing list
> >>> Development@qt-project.org
> >>> https://lists.qt-project.org/listinfo/development
> > ,
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:

> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud  >:
> >
> > On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
> wrote:
> >>
> >> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> >> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> >> > > You can download a CMake static binary (https://cmake.org/download/)
> that
> >> >
> >> > (...)
> >> >
> >> > I would prefer that our requirements be present in Linux
> distributions we
> >> > declare are supported build environments. If nothing else, our CI will
> >> > benefit from this.
> >>
> >> Let's not pull CI into it. It already
> >
> >
> > Wow! Let's not pull in the system which only goal is to validate the
> "supported platforms" promise, is it what you mean?
> > If I need a special cmake to build Qt, then this should be shipped as
> part of Qt itself, another third-party source tree.
> > And then it means that I will need to build qt's build system. In other
> words, I'll have to bootstrap Qt build system.
> > I thought that it was a big no-no. The main argument to ditch qmake and
> qbs...
>
> Hm, what is the problem with using the official CMake binaries? Isn't
> that what you'd do on Windows / macOS anyway?
>

In case you didn't follow the thread, building Qt with cmake requires a
non-released version of cmake.

The question is:
By the time qt6 will be out, will the requirement of cmake minimum version
be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)


The answer is that, best case, this is doable if qt6 is not released before
2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the minimum
req. is not bumped, which is very unlikely given the lack of support for
Android, iOS, etc...)


> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
> when it arrives, then great. But having to install the build tool from
> the vendor instead of the distro package manager surely can't be a
> blocker
>

Really? Then convince the boot2qt team to force yocto to use the latest
bleeding edge cmake version for their stable branch...
Good luck with that.

And then, which is my point, you're asking your customers to build/install
Qt build system in order to build Qt itself.
That is wrong. The world is not spinning around Qt, sorry for the bad news.
I prefer a transparent self-bootstrapped Qt over an explicit two stages one.

Right now the cmake build system doesn't respect the initial requirements
that were used to ditch contenders.

This is in no way a democratic process.
This is selective hearing, reqs for cmake are artificially lowered while
reqs for contenders are artificially raised.

I have no doubt that cmake will be Qt6 build system, this is your choice,
I'm just asking to stop this simulation, and I'm asking you to take your
responsibilities, if building Qt6 is not supported on mainstream platforms
I might consider switching away from Qt.

Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android
and whatever next os is coming.
Cmake is not yet ready for that.

Chris




> Elvis
>
> >
> > Chris
> >
> >
> >> covers installation of the cmake in
> >> order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
> >> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
> >>
> >> Cheers,
> >>   Jędrek
> >>
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki,  wrote:

> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> > > You can download a CMake static binary (https://cmake.org/download/)
> that
> >
> > (...)
> >
> > I would prefer that our requirements be present in Linux distributions we
> > declare are supported build environments. If nothing else, our CI will
> > benefit from this.
>
> Let's not pull CI into it. It already


Wow! Let's not pull in the system which only goal is to validate the
"supported platforms" promise, is it what you mean?
If I need a special cmake to build Qt, then this should be shipped as part
of Qt itself, another third-party source tree.
And then it means that I will need to build qt's build system. In other
words, I'll have to bootstrap Qt build system.
I thought that it was a big no-no. The main argument to ditch qmake and
qbs...

Chris


covers installation of the cmake in
> order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
> provisioning/common/linux/cmake_linux.sh?h=wip/cmake
> 
> )
>
> Cheers,
>   Jędrek
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor  wrote:
> On 6. Jun 2019, at 16:48, Christian Gagneraud  wrote:
> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann  wrote:
> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 02:08, Simon Hausmann  wrote:
> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
>  wrote:

[what a beautiful thread, flatten by HTML top posting where no one can
understand the history of this discussion]

> What metrics do you expect?
> With the time I had available, I discovered some issues regarding iOS + 
> CMake, but nothing insurmountable.
> I gave my analysis. We (people working on the CMake port) feel it's possible 
> to do.
> Now it's just a matter of getting to do it. But we still have other things to 
> do first.

BTW, can cmake "out of the box" deal with:
https://doc.qt.io/qt-5/qtremoteobjects-repc.html
https://doc.qt.io/QtQuickCompiler/
https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html

Last time i checked none of these were supported.

Yes, qmake support is "hackish", but that is not a good reason to
justify the near-zero support of cmake.

And let me diverge a little bit, whatever the build system chosen by
Qt *developers*,  Qt *users* should still be free to choose their own
build system. I'm including both open source users and paid customers.
That is: however *you* (qt developers) decide to use as your build
system shouldn't impact what *I* (as a Qt user) decide to use as my
own build system.
For example, you'll have to support qmake for years to come... You
like it or not.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Thu, 6 Jun 2019 at 23:46, Simon Hausmann  wrote:
>
> Hi,
>
> In the past months we, some developers from the Qt Company and KDAB,
> have made good progress on the port of Qt to use CMake as build tool.
> Since the initial prototype, the port has advanced very well and its
> current state can be summarized roughly like this:

Am I the only one to notice that this thread is just made of HTML
top-posting messages? [1]

Just sayin'

Chris

[1] https://en.wikipedia.org/wiki/Etiquette_in_technology#Netiquette
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Fri, 7 Jun 2019 at 02:25, Simon Hausmann  wrote:
>
>
> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
> > On Fri, 7 Jun 2019 at 02:08, Simon Hausmann  wrote:
> >>
> >> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> >>> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
> >>>  wrote:
> >>>> Hi,
> >>>>
> >>>> I won't hold my breath for community support for iOS. iOS is out for so 
> >>>> many
> >>>> years, yet CMake has no support for t.
> >>>>
> >>>> iOs is not a show stopper if and only you're prepared to drop this 
> >>>> plaform
> >>>> from Qt 6 in case cmake support will be poor or non existing.
> >>> IOs, Android (and other upcoming OS [1]) multi-arch  builds are IMHO a
> >>> hard-requirement.
> >>> Since when the build system "candidate" dictates Qt supported platform?
> >>> I thought it was supposed to be the other way around.
> >>>
> >>> And now people are calling for "community" help b/c they realise that
> >>> it will take a massive effort to support these requirements.
> >>
> >> FWIW, I didn't say that without support from the community nothing will
> >> happen, which is what you're suggesting. Eventually somebody from the Qt
> >> Company is likely going to dig into the particular topic of iOS, for
> >> example. If you would like to see something implemented before that
> >> point in time, then please join the development effort. We also hang out
> >> in #qt-cmake on Freenode, btw.
> > That's exactly my point, "you" took the decision before analysing the
> > problems, and now you're asking me to join #qt-cmake to make it
> > happen!?! Why would i do that? Can't you provide something that works?
> > If not, please bail out.
>
> As you can see from the responses, an analysis on CMake and iOS has been
> done, with encouraging results. These results, on conjunction with the

No, an analisys wasn't done *prior*, an analysis of the problems is
*currently* being done.
That's my feeling right now.
None of these was mentioned in your original email.

> results in the other platforms/configurations, gave us - some TqTC and
> KDAB devs - enough confidence that we think that we can pull it off. I

So you're basically saying  that you have no real metrics, just gut
feeling that it is possibly doable.
Please bring facts, not gut feelings.

> did not ask you to join to make it happen, please don't put words into
> my mouth. I said that if you'd like to see something implemented before
> we get to it, then you're invited to join the effort.

Stop saying that i put words in your mouth, i'm just reading and
interpreting what you're saying.
And right now, i've been heavily invited to something that i don't
want to join. Period.

Please stop making promises based on potential future "community
contribution" that you cannot guarantee.
We need facts, not promises and futures.

Can you multi-arch-build a Qt example/tutorial for Ios/Android right now?

Chris.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Fri, 7 Jun 2019 at 02:08, Simon Hausmann  wrote:
>
>
> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> > On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
> >  wrote:
> >> Hi,
> >>
> >> I won't hold my breath for community support for iOS. iOS is out for so 
> >> many
> >> years, yet CMake has no support for t.
> >>
> >> iOs is not a show stopper if and only you're prepared to drop this plaform
> >> from Qt 6 in case cmake support will be poor or non existing.
> > IOs, Android (and other upcoming OS [1]) multi-arch  builds are IMHO a
> > hard-requirement.
> > Since when the build system "candidate" dictates Qt supported platform?
> > I thought it was supposed to be the other way around.
> >
> > And now people are calling for "community" help b/c they realise that
> > it will take a massive effort to support these requirements.
>
>
> FWIW, I didn't say that without support from the community nothing will
> happen, which is what you're suggesting. Eventually somebody from the Qt
> Company is likely going to dig into the particular topic of iOS, for
> example. If you would like to see something implemented before that
> point in time, then please join the development effort. We also hang out
> in #qt-cmake on Freenode, btw.

That's exactly my point, "you" took the decision before analysing the
problems, and now you're asking me to join #qt-cmake to make it
happen!?! Why would i do that? Can't you provide something that works?
If not, please bail out.

> > Let's face it and be honest about that, this "build system decision" is a 
> > drill.
> > CMake has been chosen, period. Yet it doesn't seem to tick all the
> > harsh requirements set by Thiago ages ago.
> > Apparently there is an attempt to  "achieve a decision within the Qt
> > project by lazy consensus.".
> > Whatever that means.
>
> If you would like to learn more about the Qt project decision making
> process, then I can recommend the official Qt Governance Model page:
>
>
> https://wiki.qt.io/The_Qt_Governance_Model#Decision-making_process

Thanks for the point out.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Christian Gagneraud]

On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
 wrote:
>
> Hi,
>
> I won't hold my breath for community support for iOS. iOS is out for so many
> years, yet CMake has no support for t.
>
> iOs is not a show stopper if and only you're prepared to drop this plaform
> from Qt 6 in case cmake support will be poor or non existing.

IOs, Android (and other upcoming OS [1]) multi-arch  builds are IMHO a
hard-requirement.
Since when the build system "candidate" dictates Qt supported platform?
I thought it was supposed to be the other way around.

And now people are calling for "community" help b/c they realise that
it will take a massive effort to support these requirements.

Let's face it and be honest about that, this "build system decision" is a drill.
CMake has been chosen, period. Yet it doesn't seem to tick all the
harsh requirements set by Thiago ages ago.
Apparently there is an attempt to  "achieve a decision within the Qt
project by lazy consensus.".
Whatever that means.

Chris

[1] with that Huwei  story going on, i would expect a new
"android-like" OS coming very soon. Can Qt (company/project) afford to
miss that Chinese train?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] FP calculations and stability in Qt

[Christian Gagneraud]

On Mon, 13 May 2019 at 07:47, Konstantin Shegunov  wrote:
>
> Thanks for chiming in, I do appreciate the thoughts.
>
> On Sun, May 12, 2019 at 1:49 PM Christian Gagneraud  wrote:
>>
>> I use to think that Qt could do a better job about FP
>> precision/stability, but i had to realise that i was using Qt in a way
>> that it was not designed for.
>> For example, I tried to use QPainterPath, QLineF, QRectF, ... to do
>> geometry processing. And i can tell you that QPainterPath is all but
>> stable when it comes to small values. Highly zoomed-in QGraphicsView
>> based geometry object yields crazy artifacts.
>
>
> Doesn't this imply it should be dropped as an API that we can rely on?

No i don't think so, this is just an edge case. I solved it by
changing the base unit of my graphics view, so that it doesn't have to
manipulate tiny FP values.
I remember reporting that, and AFAIR, an example was an arc in a
QGraphicsPathItem rendered as as a polyline.

>
>>
>> I then turned on specialised library, Qt is a GUI toolkit, and is
>> optimised for painting. Qt takes all opportunities to be fast and
>> efficient in that context, and that includes being "mathematically"
>> imprecised, painting is all about pixels at the end of the day.
>
>
> True, arriving at those pixels is the problem, at least as far as I can tell.
>
>> Who cares where exactly a line intersect a polygon, if all you need to
>> know is if you need to paint a pixel black or red.
>
>
> Intersecting at the wrong point, means you paint the wrong pixel, right?

A pixel is a surface, everything is correct as long as the surface
covered by the pixel contains the point.
What i was trying to say, is that all geometry operations performed by
components coupled to QPainter are good enough (and very efficient)
for painting, by are not usable for "scientific" calculation.
QPainterPath is not called QPath, expecting to do precise geometry
boolean set operations with it is a mistake.
QPainterPath is good at painting path.

Actually it goes the same with QGV collision detection and point
inclusion, they are good enough for user interaction (eg which item
did the user clicked on), but are not good to decide if a point
actually belongs to a complex shape or not.

I really enjoyed using QGV, you just need to know how and when to use it.
If you're doing ECAD/MCAD stuff you do not want to use Qt for your
calculation (use eg, CGAL, OpenCascade, ...). If you're doing a 2D
game or a diagram editor, then QGV is all you need.

PS: Actually FreeCAD uses QGV, for rendering extracted 2D projections
(and other things).

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] FP calculations and stability in Qt

[Christian Gagneraud]

On Sun, 12 May 2019 at 20:26, Konstantin Shegunov  wrote:
>
> Hi,
> I'd want to clear the context out of the way, so this is the bug[1] that got 
> me thinking.
> I appreciate that we want to keep external dependencies to a minimum, and for 
> a good reason, but can we talk about how feasible it is to pull something (or 
> parts of it) in Qt, even if only internally, to facilitate stable fp 
> calculation.
>
> I've seen some complaints (on the forums mostly) about the stability of the 
> transformations Qt supplies, generally unfounded, however it'd be nice if we 
> can solve this with generality. I realize Qt is no math library and support 
> the idea to drop most of the global functions that dealt with math, in the 
> end they're already in the STL. However, as it is, we have some linear 
> algebra done (internally mostly), so I think it'd be nice to have that done 
> "correctly" for the user.
>

I use to think that Qt could do a better job about FP
precision/stability, but i had to realise that i was using Qt in a way
that it was not designed for.
For example, I tried to use QPainterPath, QLineF, QRectF, ... to do
geometry processing. And i can tell you that QPainterPath is all but
stable when it comes to small values. Highly zoomed-in QGraphicsView
based geometry object yields crazy artifacts.
I then turned on specialised library, Qt is a GUI toolkit, and is
optimised for painting. Qt takes all opportunities to be fast and
efficient in that context, and that includes being "mathematically"
imprecised, painting is all about pixels at the end of the day.
Who cares where exactly a line intersect a polygon, if all you need to
know is if you need to paint a pixel black or red.

To summarise:
I ended up using "proper" geometry processing library for the "model"
and used Qt to do the rendering (the view).
It came at a cost, but in the long term was a big win.

Chris

> I'd appreciate feelings and opinions on the matter, as I'm but one person and 
> my view is rather limited.
>
> [1]: https://bugreports.qt.io/browse/QTBUG-75146
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWebEngine file path too long

[Christian Gagneraud]

On Tue, 12 Mar 2019 at 23:45, Samuel Gaist  wrote:
>
> Hi,
>
> I’ve been hit by this surprising error when building QtWebEngine.

I had this issue too, i fixed it by patching chromium build system,
see attached patch (i'm not the author and i don't have the original
url).
This was with Qt-5.11, with Qt-5.12 this patch is not needed anymore.

Chris
diff --git qt-everywhere-src-5.11.0/qtwebengine/src/3rdparty/chromium/tools/gn/ninja_action_target_writer.cc qt-everywhere-src-5.11.0/qtwebengine/src/3rdparty/chromium/tools/gn/ninja_action_target_writer.cc
index a5bc6cd..5cefbfe 100644
--- qt-everywhere-src-5.11.0/qtwebengine/src/3rdparty/chromium/tools/gn/ninja_action_target_writer.cc
+++ qt-everywhere-src-5.11.0/qtwebengine/src/3rdparty/chromium/tools/gn/ninja_action_target_writer.cc
@@ -115,9 +115,18 @@ std::string NinjaActionTargetWriter::WriteRuleDefinition() {
 // strictly necessary for regular one-shot actions, but it's easier to
 // just always define unique_name.
 std::string rspfile = custom_rule_name;
+
+//quick workaround if filename length > 255 - ".rsp", just cut the dirs starting from the end
+//please note ".$unique_name" is not used at the moment
+int pos = 0;
+std::string delimiter("_");
+while (rspfile.length() > 251 && (pos = rspfile.find_last_of(delimiter)) != std::string::npos)
+rspfile = rspfile.substr(0,pos);
+
 if (!target_->sources().empty())
   rspfile += ".$unique_name";
 rspfile += ".rsp";
+
 out_ << "  rspfile = " << rspfile << std::endl;
 
 // Response file contents.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] nmake qtcreator from source failed

[Christian Gagneraud]

On Mon, 25 Feb 2019 17:58 mirchd,  wrote:

> Hello,
>

You'll have better luck on qt creator mailing list, as it seems you're
trying to build it.

It might help to give qtc version along compiler/os env and version.

Chris


> it says,
> --
> link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /DLL /SUBSYSTEM:WINDOWS
> /VERSION:1.12 /MANIFEST:embed
> /OUT:..\..\..\..\..\..\lib\qtcreator\qbscored1.dll
> @C:\Users\CHENDI~1.NIN\AppData\Local\Temp\nmAFA0.tmp
>   create lib ..\..\..\..\..\..\lib\qtcreator\qbscored1.lib
> ..\..\..\..\..\..\lib\qtcreator\qbscored1.exp
> moc_executor.obj : error LNK2001: *unresolved external symbol* "public:
> int __cdecl qbs::JobLimits::getLimit(class QString const &)const "
> (?getLimit@JobLimits@qbs@@QEBAHAEBVQString@@@Z)
>
> --
> vs2017 win10 branch:master
>
> please help,
>
> Best Wishes,
> Dian Chen
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Mailing list archive annoyance

[Christian Gagneraud]

Hi all,

I do not know what is going on with the mailing list archive, but this
is getting frustrating.
Trying to move forward and keep positive, i would like to report on
a(nother) use case here: https://bugreports.qt.io/browse/QTBUG-71225
This bug report starts with a couple of links to the Qt Interest ML
archive, in an attempt to give some background.This qt.io Jira ticket
is linked into our own bug tracking system. Yet, all these mailing
list archive hyperlinks yield a so-called HTTP 404.This is quite
annoying. History seems to be gone for ever.

Can you guys recover the mailing list archive, like nobody will ever
notice what has happened? Can you do that? Yes or No?

Or should we switch (back) the Qt mailing list management to the community?

Who is in charge of the qt-project.org domain?

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 8 Jan 2019 at 02:42, Edward Welbourne  wrote:
>
> On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote:
> >> But in this day and age where docker works everywhere I don't really
> >> see the point in fighting to make windows behave like a proper unix
> >> system, just write a dockerscript that does your cross-compile job.
>
> Christian Gagneraud (17 December 2018 13:50)
> > What do you mean by 'everywhere'? Native Windows dockers are still
> > experimental, and i haven't heard of native MacOS docker yet (might
> > have missed smth).
>
> I can't speak for "everywhere"; but we've found that docker works
> cross-platform enough for the needs of our on-going work to replace the
> monolithic net-test-server currently used to test network-related code:
>
> https://codereview.qt-project.org/240564 - macOS
> https://codereview.qt-project.org/246535 - MS-Win
>
> So there is at least some grounds to hope docker can solve the
> cross-compilation problems Jean-Michaël had in mind.

Not sure to understand your point, AFAIU (and i had a quick look at
the commits above), you're using "docker for windows" and "docker for
mac".
These 2 run a Linux VM on Windows/Mac in which a Linux docker server
is running, so at the end you're running Linux docker inside a Linux
VM on Windows/Mac, not a Windows/Mac "native docker image".
I do not see how it can helps with cross compiling...
From my POV, i would like to see docker solves native builds, not cross builds.

Using Linux docker images for network integration testing is a very
good idea, thought.

Now, things get complicated since the introduction of "native" Windows
containers, that is a pure "Windows" docker containers running on
Windows 10 (10 GB for a core image). So far MacOS "native" docker
containers don't exists yet.

Coin uses Nebula to manage VMs of all sorts (that's my understanding),
and i think that the Qt Company did a mistake here:
Forget about custom CI, focus on custom build system (after all that
is the topic of this thread).
My own, cheap/useless opinion is that the Qt company should have
contacted gitlab or the like...
Look at what they did with Drupal.

Chris.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier
 wrote:
> > CMake doesn't support (very well) cross-compilation for android on
> > Windows for example,
>
> fairly interesting considering that Android Studio uses CMake: 
> https://developer.android.com/studio/projects/add-native-code

Fairly interesting indeed, and very surprising too, this WIN32/Android
stuff was fixed last week, i didn't invent it.
Maybe, we ran into bad luck.

> They used to use Gradle but saw the light at some point :-) (or at least the 
> incredible pain that gradle was inflicting on their end-users).

AFAIU,  you still need graddle with Android Studio and/or Cmake, to
deal with some "details" like packaging, manifest, resources,
multi-arch, ...

Here comes my ignorance of the tool, I'll direct my questions to
qt-interest or cmake ML for point outs.

>
> But in this day and age where docker works everywhere I don't really see the 
> point in fighting to make windows behave like a proper unix system, just 
> write a dockerscript that does your cross-compile job.

What do you mean by 'everywhere'? Native Windows dockers are still
experimental, and i haven't heard of native MacOS docker yet (might
have missed smth).
Automating Linux/Android with Linux is the easiest part.

> Also, there's WSL, I suppose that it should work somehow.

I've tried that, on a native Windows machine (and it's not compatible
with Virtual Box for whatever reason - HyperV responsability?).
I have no interest to run LOW ("Linux on Windows", that is what it
should be called: it produces Linux binaries).
I've tried as well Linux docker for windows (again, no interest, and
it requires VB), last resort is windows docker for windows...
it's coming and it's BIG (10 GB for a 'core' layer)

> > I've never tried, but i'm sure it shouldn't be that hard to add
> support for VHDL/Verilog to Qbs, that's the power of modern SW
> architectures.
>
> what makes you think that it wouldn't work with CMake too ?
> e.g. it supported java for a long time 
> (https://cmake.org/cmake/help/latest/module/UseJava.html), and C# since 3.8 
> (https://cmake.org/cmake/help/latest/module/CSharpUtilities.html)
>
> Here's a simple example of FPGA toolchain (again, 5 seconds of google) : 
> https://github.com/jamieiles/fpga-cmake

Latest commit dc10370 on Aug 15, 2017.
It's an example of a CMake-based project using a dedicated FPGA
workflow (not a CMake toolchain, nor VHDL/Verilog), targeted at a very
specific family of FPGA.
Quartus is Altera's old "IDE", Altera manufactures FPGA and was bought
by Intel few years ago (15B$) [1][2]
I've used it, like any student of my time/space.
They have a free (as in free beer) versions for
students/academic/hobbyist, that you can run from the command line...
GNU make would be fine with dealing with this example project, i would
say that 10 SLOCs are enough.

Chris

[1] 
https://newsroom.intel.com/news-releases/intel-completes-acquisition-of-altera/
[2] https://en.wikipedia.org/wiki/Altera
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 17:53, Ray Donnelly  wrote:
> On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt > The discussion about build systems reminds me a bit of a religious war. I
>> made my peace with CMake and use it only when being paid for. It allows me
>> to use the browser more often and to find obscure stuff on the internet.
>> It's an expensive tool. After work I want to get my stuff done with low
>> investment, hence I often use Qbs ;-)
>
> That sounds like a very sensible approach Richard.

Same here. At work, we're attempting at using CMake to do Android
builds, but once back at home, i switch to Qbs.

The funny part, is that lot of people at work think that i am the
'CMake expert', you should see their face when i tell them what i
think about CMake (nothing rude or wild, but definitely negative).
After that i try to help as much as i can. The reason being that I do
care about how we cross-build stuff, and how maintainable our build
recipes are, whatever the tool we use.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 18:38, Thiago Macieira  wrote:
>
> On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote:
> > ... and if you cross-compile, you definetly don't want to your build system
> > to stick its nose into your system librararies on any platform.
>
> No, you really DO. The issue is what "system" is: it's the sysroot for your
> target platform, not the host system where you're building from.
>
> A good buildsystem should have support for being told where the sysroot and
> cross-compiler are, then execute pkg-config and .cmake file searches there.
> When installing, it also needs to be able to install to a separate install
> root, so it can be packaged. Installing into the sysroot is optional: it's
> only a convenience.

That's sound pretty standard stuff to me.

Does pkg-config and cmake works on Qnx and Windows? Can you cross
compile for iOS, tvOS, ... using CMake?
Has it been ever tried once?
CMake doesn't support (very well) cross-compilation for android on
Windows for example, although, it pretends to be multi-platform and
honor/embrace sysroot...

>
> Of course, this assumes that the libraries to be found do not require
> executing anything from the sysroot. This is not an issue of the buildsystem
> though: the problem is the dependency itself and would happen regardless of
> buildsystem.

Yes, autoconf got around that with site cache, a lng time ago.

>
> So, in general, cross-compiling is difficult and error-prone. That's why
> solutions like Yocto Project attempt at cross-compiling as if it were native,
> via qemu and pseudo. And that's why I don't cross-compile.

I've been cross-compiling and cross-debugging for 20 years, yes it's
not always easy, but at the end of the day it's always the same
symptoms, so once you know the arcane and your tools, it's not that
bad.
Things get only interesting when you attempt "canadian" cross-build of
your SDK, where your build machine, your host machine and your target
machine are 3 different arch/OS (and you do not "cheat" with
emulators).
It's very hard, fun (or not) but very rewarding.

Yocto is not the only thing on the planet, there's lot of meta build
system around that does cross-compile everything and are way easier to
use, read, write and understand.

You obviously don't do bare metal dev either, as there is not such
thing as native build, not even emulated since there is no "real" OS.
Even if there were one, you do not want to feel the pain to
native-build on a N MHz processor - where n < 100, sometimes < 10.
I wonder how many days it will take to build a full-featured boot2qt
from scratch on a native ARM machine.

FYI, you can do bare-metal development with Qbs and QtCreator, and
that's pretty cool.

I've never tried, but i'm sure it shouldn't be that hard to add
support for VHDL/Verilog to Qbs, that's the power of modern SW
architectures.
And then QtCreator's solid code base (SW arch again?) would help to
add FPGA deployment and simulation support, adding support for JTAG
probes, this would even attract bootloader and kernel developers too.

Just look at how LLVM made it in a all-gcc world. Everyone wants to
use LLVM these days, their architecture was a true revolution (in the
Open Source world at least) and is the key to their success.
Would you say in 2018, that LLVM is the wolf? And as such, everyone
should stick to gcc? No, you  wouldn't, nobody would.

What's important is not the critical mass, it's the rate at which you gain mass.

Chris

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Christian Gagneraud]

On Sat, 15 Dec 2018 at 01:59, Kevin Kofler  wrote:
> >> This is a bug that was already fixed by:
> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/2668
> >
> > Apparently it will make it into 3.14, in 2 months.
> > It's a bummer to have to maintain a work around, or should i add cmake
> > to my toolkit, so that i can keep track of patches?
>
> Technically, the simplest workaround would be to just not use Windows as the
> build host for cross compilation. :-)

That's a no-go, most of our developers use Windows.

> But I guess producing a cmake.exe with
> the patch backported or from a git snapshot as a one-off workaround, or even
> just pointing to the nightly snapshot binaries from:
> https://cmake.org/files/dev/?C=M;O=D
> would be the easiest workaround to put in place.

Yes that could be a possibility, the only issue with that is i cannot
use `cmake_minimum_required(VERSION 3.xy)` to make sure developers use
the right version.
And once 3.14 is released, i won't have any ways to check if
developers uses 3.14 'special' or 3.14 'official'.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Remove artemis_poo...@aol.com from list (spammer)

[Christian Gagneraud]

On Sat, 15 Dec 2018 at 05:19, Jason H  wrote:
>
> I request removal of artemis_poo...@aol.com for spam. Email can be forwarded 
> to the appropriate party.
> Have others gotten a direct reply?

Yes, i have received 4 phishing attempts from this email.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Christian Gagneraud]

On Fri, 14 Dec 2018 at 00:54, Kevin Kofler  wrote:
> This is a bug that was already fixed by:
> https://gitlab.kitware.com/cmake/cmake/merge_requests/2668

Apparently it will make it into 3.14, in 2 months.
It's a bummer to have to maintain a work around, or should i add cmake
to my toolkit, so that i can keep track of patches?
Do you foresee more problems like that?

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Christian Gagneraud]

Hi Kevin,

On Fri, 14 Dec 2018 at 00:54, Kevin Kofler  wrote:
> Bootstrapping QMake has always been the least pleasant part of the Qt build
> process.

Yes, i think we all agree on that one.

> I am looking forward to this bootstrapping hack going away by just using
> CMake.

So you want to replace a bunch of scripts with another bunch of
scripts, and magically the maintenance burden will be gone?
My bet is that it will never happen, you'll still need the power of
perl, python or javascript to do the "dirty job", CMake is not
expressive enough, by design.

> > Can you point me to something that shows the Qt "project" contributing
> > to the Qt "company" on that very particular topic?
> The Qt Project is largely just the Qt Company when it comes to such core
> tasks.

It seems that you cannot point me to something tangible.

> > The Qt Company has been looking for "employees" to work on Qbs for
> > month before dropping it, apparently nobody responded, or something...
>
> Then that would pretty much explain why they cannot maintain it in the long
> run.

You are right, and it would be nice to have official statements on
that. What did really happen?

> > read that one:
> > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
>
> That is a powerful feature. And you don't have to use it if you don't need
> it. Most CMake files actually do not need or use output expressions.

It's not just the output expressions, the whole page "smells bad".
Take '$' for example, it reminds me of m4, make and qmake, like
we haven't moved away from the old daemons.

> > And read that again and again, until you brain says: 'Actually, CMake
> > is "crap"!'
>
> My brain refuses to enter this infinite loop. ;-)

Mine too. :-p

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Christian Gagneraud]

On Thu, 13 Dec 2018 at 12:27, Kevin Kofler  wrote:
Hi Kevin,
> > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
>
> Because CMake is a widespread tool written in C++/STL

Some people are scared of the wolf, i'm scared of the sheepple.

> (so, unlike QBS, it
> does not depend on Qt, which would mean a circular dependency when building
> Qt),

qmake has this problem, yet it's been packaged for 10+ years without a problem.

> widely packaged for GNU/Linux distributions, and with binaries for
> Windows and macOS shipped by CMake upstream (Kitware) themselves. It has a
> live upstream at Kitware, so Qt does not have to maintain it. And it is
> already widely used in the Qt and KDE community.

What a bunch of cheap free statements, w/o proper comparison.

>
> QBS, on the other hand, is a custom tool, in practice only used by Qt and a
> few Qt-using projects (I know the aim is to support also non-Qt projects,
> but this is not really used in the wild), which requires constant
> maintenance effort from the Qt project.

Can you point me to something that shows the Qt "project" contributing
to the Qt "company" on that very particular topic?
The Qt Company has been looking for "employees" to work on Qbs for
month before dropping it, apparently nobody responded, or something...

> >  From my point of view, the CMake it is a crap...
>
> CMake is not a "crap", it is a powerful tool, almost as easy to use as
> QMake, but a lot more flexible and powerful.

Cmake is crap, it is a macro based language, like it's good to be back
in the 80's.
It has no semantic, and no concept apart form 'macro', the syntax
sucks, big time, every thing is just 'expression', read that one:
https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
And read that again and again, until you brain says: 'Actually, CMake
is "crap"!'

>
> > I know, that I'm not a CMake expert, but Why I need to spent a lot time
> > to make the CMake working wich an unknown result,
> > instead of just using QBS? Cross-compilation with QBS works
> > immediatelly, but with CMake sucks!
>
> Once you have the cross toolchain configured properly, which is a one-time
> setup effort, CMake will just work, too.

Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation
doesn't actually exists (yet) on Windows:
https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7

I'm telling you: with CMake, it's 1988 Christmas, right now!

Chris.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

> I was told, there's a qbs.io or something going on?

Wow, kudo to whoever, qbs.io redirects to doc.qt.io/qbs

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

On Sat, 3 Nov 2018 at 01:15, Martin Smith  wrote:
>
> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent - Nothing 
> >personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But "dropped Qbs" means The Qt Company won't be developing Qbs anymore, which 
> means, effectively, Qbs is being handed to the Qt Project community.


Community? Like http://qt-project.org? There's no such thing,
everything is controlled by qt.io. Let's face it, just do a pen test
of qt.io, qt-project.org and digia.com to see how things are
organised.


I was told, there's a qbs.io or something going on?

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
>
>
> On 2 Nov 2018, at 11:45, Christian Gagneraud  wrote:
>
> On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
>  wrote:
>
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian 
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for, 
> it's not a justification for my actions.
> Creating an hostile environment is bad for the community and I should not 
> have done it.
> It won't happen again,
> Regards,
> Luca
>
>
> Hi All,
>
> I would  like to apologise as well, my sarcasm and my provocation went
> uncontrolled.
> My fault, this was definitely not the most clever way to get things sorted.
> I'm looking forward HTTPS://lists.qt-project.org to be back online and
> would like to thanks everyone working on the matter.
>
>
> Thanks Chris and Luca.
>
> Getting lists.qt-project.org fixed is being worked on. I hope it’s won’t be 
> too long.
>
> But there’s something to take away for TQtC as the party taking care of the 
> infrastructure here. TQtC needs to establish some more pro-active monitoring 
> of the infrastructure so that these things will get ideally get fixed before 
> they become a problem next time. I’ll see what I can do to help getting that 
> in place.



Hi Lars,

You've just dropped Qbs, what's next?
I don't trust you anymore, nor the company-ies you represent - Nothing personal.
I think that it is time for the qt-project.org domain to be handed
back to the Qt Project community.
I was reading a french article this morning
(https://linuxfr.org/news/fedora-29), i give you an inaccurate, but
syntactic and compact translation of the article introduction:

Fedora is a GNU/Linux distribution developed by the Fedora Project and
sponsored by Red Hat that provide them with developers, finance and
logistics.
Fedora can be seen as an open source technological show case of Red
Hat proprietary technology. (NDLR: Free and inaccurate translation, i
mean it)
=> sold for 34 billions dollars

How do you fell about that? Do you see similarities?

Is the triple-licensed Qt stack an open source technological show case
of what the Qt Company has to offer?


More seriously, yes, Fedora/RedHat  and
Qt/Project/Company/Digia/Nokia/Microsoft/TrollTech are different beast
(apple and oranges, yadi, yada, ...).
But I see similarities. (and i do not care about the 34 billions)

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
 wrote:
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian 
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for, 
> it's not a justification for my actions.
> Creating an hostile environment is bad for the community and I should not 
> have done it.
> It won't happen again,
> Regards,
> Luca

Hi All,

I would  like to apologise as well, my sarcasm and my provocation went
uncontrolled.
My fault, this was definitely not the most clever way to get things sorted.
I'm looking forward HTTPS://lists.qt-project.org to be back online and
would like to thanks everyone working on the matter.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

On Thu, 1 Nov 2018 at 05:28, Kain Vampire via Development
 wrote:
>
> WHAT A TWAT!
>
> P.S.
>
> Yes, feel free to ban me, it was worth it.

Was it?

You could have used the word 'idiot', at least it is not an insult to
the feminine gender.
You could have as well quoted which part of the message you didn't
like. I'm taking you didn't like part 2.
This was obviously a provocative statement, but it was not an insult.

I still stand that the qt-projects.org domain should not be managed
(directly or indirectly) by the Qt Company, there is a clear conflict
of interest.
Something that has been raised several times in the past (Check the
mailing list archives about the captive/deceptive portal hat is/was
the Qt's download page).
lists.qt-projects.org has had issue for more than a month, and
(suddenly) got resolved overnight.
[Side note: http stopped to redirect to https, but https is still
down, which means that https urls returned by search engine are
broken. Whoever runs codereview.qt-project.org has access to a
wildcard ssl certificate (*.qt-project.org), but it seems that whoever
runs lists.qt-project.org doesn't.]

As an experience, try to type "download qt" in you favorite search
engine, and tell me what you get, here is my top results:
https://www.qt.io/download
https://www1.qt.io/offline-installers/
https://download.qt.io/archive/qt/
qt-project.org/downloads

The interesting bit is that  qt-project.org/downloads redirects to
https://www.qt.io/download.

Basically, qt-projects.org is just a facade to qt.io, I think this is
not healthy. There is no public expression of the "Qt Project".
Concerning, the "Qt Project Hosting Foundation", i've found:
https://wiki.qt.io/Qt-contributors-summit-2014-QtCS2104_Foundation
https://investors.qt.io/governance/management/ (where it is mentioned
that Tuukka Turunen is a "Chairman of the Board of Directors in the Qt
Project Hosting Foundation")
http://website.informer.com/Cristina+Hamley+Qt+Project+Hosting+Foundation.html


Chris

PS: I do not hate the Qt Company, nor do I hate anyone working for
them. Without license, without money, there would be no "Qt Company",
and without "Qt Company", the "Qt Project" would be substantially
different. As a license owner and an OSS enthusiast I am thankful to
the Qt Company and to all numerous direct and indirect "Qt Project"
contributors.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

On Thu, 1 Nov 2018 at 02:53, Andy Shaw  wrote:
>
> It is there, but you have to go to http://lists.qt-project.org for now, it is 
> being moved to a new server so at some point the https address will be back, 
> but until then you need to use the http address.

In case you're not aware, HTTP is being deprecated, and modern,
up-to-date web browser will redirect you to HTTPS/443 if it is
available.
If lists.qt-project.org doesn't support HTTPS, then it shouldn't
answer on port 443.
To be clear: my web browser will redirect me to https automatically
because https is port 443 and port 443 on lists.qt-project.org is open
and responding.
The issue is that port 443 is serving plain HTTP instead of HTTPS.

In a broader statement, i'm questioning the fitness of the Qt company
to manage the qt-project.org domain.
Obviously the Qt company is not making any money with qt-project.org,
so please hand it over to the community.

Chris

>
> Andy
>
> Development på vegne av Christian Gagneraud 
>  chg...@gmail.com> skrev følgende den 31.10.2018, 14:36:
>
> Hi,
>
> Can we have Qt mailing list archive back?
> I believe it is tracked by
> https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for
> weeks. Can the "Qt Project Hosting Foundation" (from whois record)
> take care of that?
> What is going on?
>
> Chris
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Who is in charge of qt-project.org?

[Christian Gagneraud]

Hi,

Can we have Qt mailing list archive back?
I believe it is tracked by
https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for
weeks. Can the "Qt Project Hosting Foundation" (from whois record)
take care of that?
What is going on?

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 22:47, Christian Kandeler
 wrote:
>
> On Wed, 31 Oct 2018 10:44:43 +1300
> Christian Gagneraud  wrote:
>
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  
> > wrote:
> > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > The only thing I'm criticising is that its proper chance involves Qt 
> > > being the
> > > guinea pig. Find someone else instead and grow your community. Get track
> > > record for building, cross-compiling, working with weird set ups,
> > > containerised build environments, build farms, etc. Don't ask Qt to 
> > > switch to
> > > it until you've done that work.
> >
> > !?!
> > What make you think qbs cannot be used in such environments?That all
> > very basic stuff to me.
> > - cross-compiling: Qbs support *out of the box* all "standard" OS
> > *and* "standard" toolchains.
> > - working with weird set ups: what does that even mean? That a very
> > vague statement.
> > - containerised build: any build system can run in a container, that's
> > orthogonal.
> > - build farms: Against what is the problem with build farm, i don't get it.
> > - etc: again, can you elaborate? that's very vague.
> >
> > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all
> > producing platform specific installers.
> > It was a breeze.
> > I've used it to build a 1.5 million SLOC SW, with complex build
> > matrix. The only reason we dropped it, was because of lack of
> > integration:
> > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing
> > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual
> > Code, Eclipse, ... integration.
> > And, so far, we failed at switching to CMake, the build matrix is too 
> > complex.
>
> So what *are* you using now? Just curious.

Drum roll. vcxproj + python + qmake!
This is close to a 'hand crafted' build system, it is dirty, fragile,
but "it works" (tm).
The middle man, python, is where we have full freedom to do the dirty
tweaking job.
We even have python code that "fix" the generated Makefiles, when needed.
Absolutely nobody likes this solution, it is heinous,  but it is the
only one that fulfill all our requirements.
With enough energy, i'm sure this whole thing could be switched to
Qbs, CMake or even qmake.
But I do believe that Qbs would be the cleanest solution.
Now, of these 3 build systems, CMake is the only one that is supported
by Visual Studio (I was told), and although i do not use it, this is
the most common IDE here.

We do hundreds of builds per days, for ca. 15 different build
configurations, and we do that in containers, in a build farm.
We're even experimenting with Windows native containers, and
off-loading our local build farm in the cloud.
We build the whole custom embedded Linux OS as well, a bunch of
in-house shell scripts that have to deal with at least the most common
build systems.
We have tera-bytes of artifacts every day. We generate firmwares for
at least 50 commercial products, every day.
Yes it's not an easy job, and CMake vs qmake vs Qbs doesn't influence
the number of issue we have to face.

Hence my criticism toward Thiago's requirements and arguments. I don't
buy a single line of what he said in this thread.

Last but not least, everyone maintaining a Embedded Linux Distro have
to maintain a set of patches to work around buggy source package build
system, and this includes Qt, see for example:
https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qt5/qtbase
See as well debian/patches in, eg
http://http.debian.net/debian/pool/main/q/qtbase-opensource-src/qtbase-opensource-src_5.3.2+dfsg-4+deb8u2.debian.tar.xz

Whatever the build system you use, your users will have to work it
around and deal with it.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 11:08, Thiago Macieira  wrote:
> On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira 
> wrote:
> > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > The only thing I'm criticising is that its proper chance involves Qt being
> > > the guinea pig. Find someone else instead and grow your community. Get
> > > track record for building, cross-compiling, working with weird set ups,
> > > containerised build environments, build farms, etc. Don't ask Qt to switch
> > > to it until you've done that work.
> >
> > !?!
> > What make you think qbs cannot be used in such environments?That all
>
> I didn't say it can't. I'm saying I want proof that it can, by having other
> projects adopt the solution and there being track record of it.
>
> > very basic stuff to me.
> > - cross-compiling: Qbs support *out of the box* all "standard" OS
> > *and* "standard" toolchains.
> > - working with weird set ups: what does that even mean? That a very
> > vague statement.
>
> See the July email for more details.
>
> > - containerised build: any build system can run in a container, that's
> > orthogonal.
>
> Until you run into trouble. Example of what I literally had a problem with in
> the last 30 minutes: Maven.
>
> [ERROR] Failed to execute goal on project hadoop-auth: Could not resolve
> dependencies for project org.apache.hadoop:hadoop-auth:jar:2.8.5: Failed to
> collect dependencies at com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Failed to
> read artifact descriptor for com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Could
> not transfer artifact com.nimbusds:nimbus-jose-jwt:pom:4.41.1 from/to
> apache.snapshots.https (https://repository.apache.org/content/repositories/
> snapshots): repository.apache.org: No address associated with hostname ->
> [Help 1]
>
> Who do I turn to for help? A quick set of Google queries did not result in an
> answer on how to properly populate the dependencies for this thing (Apache
> Hadoop) .

Your problem has nothing to do with containers, unplug the network
cable of your computer, and you'll have the same issue on your host.

But that's an interesting 'issue', one that even contradict some of
your requirements, like containerised, build farm, supported by Linux
distro, ...
I'm pretty sure that the build system used by Apache Hadoop meet all
your requirements, yet in your particular use case, it fails ...

So your long list of requirement cannot even bring the guarantees
you're seeking.

I'm not trying to say that your requirements are bad or useless, i'm
just saying that in themselves, they don't even bring any guarantees,
that's all.


> > - build farms: Against what is the problem with build farm, i don't get it.
>
> There's no problem until there's a problem. Can you point me to something that
> uses qbs to build getting built in a Linux distribution's build farm? I'd like
> to know that it's been properly tested.
>
> It's small things like libraries ending up in /usr/lib64 instead of /usr/lib.
> Some build systems do that automatically for you; with some others you can get
> it wrong. And here's the buildsystem that failed to install libraries in the
> right place this morning: CMake.

Packagers have to deal with that all the time, and people doing
cross-compilation have to deal with even worse things every day.
Even if you use the perfect tool, the author of the build recipe can
still screw it up.

Given who's behind Qbs, I have high expectation for Qbs to do 'the right thing'.

Chris


> > - etc: again, can you elaborate? that's very vague.
>
> I did, three months ago.
>
> > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all
> > producing platform specific installers.
> > It was a breeze.
> > I've used it to build a 1.5 million SLOC SW, with complex build
> > matrix.
>
> Great. That's good track record. Now get 3 Linux distributions to package it.
>
> > The only reason we dropped it, was because of lack of
> > integration:
> > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing
> > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual
> > Code, Eclipse, ... integration.
> > And, so far, we failed at switching to CMake, the build matrix is too
> > complex.
>
> I didn't call for IDE support in my email. Tobias, in a reply to it, did.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

Hi Lars,

On Tue, 30 Oct 2018 at 23:42, Lars Knoll  wrote:
> > On 30 Oct 2018, at 05:00, Christian Gagneraud  wrote:
> > On Tue, 30 Oct 2018 at 01:17, Lars Knoll  wrote:
> > Then why spend energy/money to fix something that is broken by design?
> > (Again, that is a personal opinion, if needed to say)
>
> As I said in my email, I unfortunately don’t see a way how The Qt Company can 
> push Qbs forward. It was a difficult decision because I very much like the 
> ideas and the technology used in Qbs.
>
> From the perspective of a company, we have to justify investments we do, and 
> they have to make sense not only from a perspective of being cool technology, 
> but also how they can in the end generate business for us. In addition, 
> there’s always the question, what we then can’t do (because the total money 
> we can invest in R is limited).
>
> Looking at the fact, that we can’t earn money on a build system and that it 
> would require quite a lot of funding to make it more than a niche product it 
> doesn’t make sense to pursue it further. Instead we would rather use the 
> money to improve Qt and Qt Creator.

This doesn't add up, why did you develop and still develop and
maintain 'coin' then?
You're not making money with it. It's costing you (a lot?) and is a
critical part of your QA infra.

> > - Did Jake left the QtC due to your early decision to drop qbs? ( I
> > personally do think that the decision was taken long time ago)
>
> The decision to not continue to develop Qbs was done very recently. It 
> doesn’t make sense to make a decision and then not take actions. Whatever the 
> reasons Jake left, they have nothing to do with this.

I believe you.

Thanks,
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  wrote:
> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> The only thing I'm criticising is that its proper chance involves Qt being the
> guinea pig. Find someone else instead and grow your community. Get track
> record for building, cross-compiling, working with weird set ups,
> containerised build environments, build farms, etc. Don't ask Qt to switch to
> it until you've done that work.

!?!
What make you think qbs cannot be used in such environments?That all
very basic stuff to me.
- cross-compiling: Qbs support *out of the box* all "standard" OS
*and* "standard" toolchains.
- working with weird set ups: what does that even mean? That a very
vague statement.
- containerised build: any build system can run in a container, that's
orthogonal.
- build farms: Against what is the problem with build farm, i don't get it.
- etc: again, can you elaborate? that's very vague.

I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all
producing platform specific installers.
It was a breeze.
I've used it to build a 1.5 million SLOC SW, with complex build
matrix. The only reason we dropped it, was because of lack of
integration:
QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing
long time ago, Qbs won't take off without XCode, Visual Stidio, Visual
Code, Eclipse, ... integration.
And, so far, we failed at switching to CMake, the build matrix is too complex.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

> > On 30 Oct 2018, at 05:00, Christian Gagneraud  wrote:
> > - Any track record that Qbs was not fit for the job? (Please no "we
> > can't build Qt with it", as you cannot build Qt with anything but
> > qmake right now)
>
> No, of course one could have made it support building Qt. There were some 
> missing items like the configuration system and some other things, all of 
> those could of course have been implemented.

How CMake will solve the 'configuration' problem. Will CMake allow us
to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
Everyone is bragging about open source (me first), but the Qt market
is medical, automotive and avionics/space industry, isn't it? How will
CMake cope with that?
CMake is not even aware that they are other OS behind WIndows and
Linux Desktop

Just Sayin'.
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 30 Oct 2018 at 22:50, Denis Shienkov  wrote:
> == R I P, QBS ==

Please stop these "RIP", you're cautioning a burial ceremony that is
just pure speculation so far.
"CMake will fail" (tm) [another burial ceremony that is just pure
speculation so far]

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 30 Oct 2018 at 22:18, Richard Weickelt  wrote:
>
> Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/
> > No conspiracy here, but i have a few more questions (not related, in
> > no particular order)
> > - Did Jake left the QtC due to your early decision to drop qbs? ( I
> > personally do think that the decision was taken long time ago)
> > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt 
> > Script?
> > - Any track record that Qbs was not fit for the job? (Please no "we
> > can't build Qt with it", as you cannot build Qt with anything but
> > qmake right now)
>
> Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list in
> June? I asked him explicitly for more transparency about the decision-making
> process about the future of Qbs. Apart from a vague promise, I heard nothing
> back.

,https://lists.qt-project.org/mailman/listinfo/qbs gives me:
Secure Connection Failed
An error occurred during a connection to lists.qt-project.org. SSL
received a record that exceeded the maximum permissible length. Error
code: SSL_ERROR_RX_RECORD_TOO_LONG

As reported on qt-interest recently, lists.qt-project.org is serving
plain HTTP over port 443.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 30 Oct 2018 at 01:17, Lars Knoll  wrote:
>
> Hi all,

Hi Lars,

Playing the devil's advocate here.

May I ask: Which democratic/meritocratic  process was used to take
this decision?
I do understand that the QtC is the Qbs instigator/maintainer, so
nobody can blame you for pulling the plug off and adjusting resources
allocation.

Who/when/where was the decision of switching to CMake taken?
Any trace record? A vote, a ballot, something? I havent's hear of any
"Qt Project" event/announcement recently.
So far i've seen some broad (but useful) un-authoritative requirements
from Thiago,
followed by a lengthy (endless) discussion, and suddenly your email
that seems to announce the result of the "election".
When did the election happened?

So some claims that build systems are no "The Qt Company" business,
yet you're about to take the road of having to bend a dinosaur (CMake,
that's a personal opinion) to suit your modern requirements.
Are you planning to have Qt employees fix CMake?

Then why spend energy/money to fix something that is broken by design?
(Again, that is a personal opinion, if needed to say)

No conspiracy here, but i have a few more questions (not related, in
no particular order)
- Did Jake left the QtC due to your early decision to drop qbs? ( I
personally do think that the decision was taken long time ago)
- Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script?
- Any track record that Qbs was not fit for the job? (Please no "we
can't build Qt with it", as you cannot build Qt with anything but
qmake right now)

Sincerely,
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 30 Oct 2018 at 20:47, Иван Комиссаров  wrote:
> Иван Комиссаров
> > 30 окт. 2018 г., в 4:34, Thiago Macieira  
> > написал(а):
> > Can you name any project of moderate complexity using it?
> >
>
> How about Qt creator? How about commercial projects?
>
> But what I would like to ask is how about porting Qt Creator to cmake first, 
> before porting Qt? Of course, this is not as fun as porting Qt but we can 
> _compare_ all three build tools on that project. It is huge, uses code 
> generation so it was a good playground for qbs. Why not use it as a 
> playground for cmake? Then we'all have _numbers_ (speed, project files size 
> and so on)
>

+1, if you cannot port QtCreator to CMake, then you have no chance to
port Qt to Cmake.
Both QtCreator and Qbs can be built and developed using QtCreator+Qbs.

Interesting experience: port Qbs and QtCreator to CMake and let see
what sort of experience it is to develop QtCreator and Qbs using
QtCreator+CMake.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

Warning: Free sarcasm, i'm not serious (well, maybe a little bit...)

On Tue, 30 Oct 2018 at 18:29,  wrote:
>
> Honestly I feel very disappointed as well with this decision. I feel 
> similarly to others, Qbs is now being phased out so fast (half a year of 
> development, another half a year of maintanance after that it seems). So 
> better get to porting stuff to CMake right away. Having experience with CMake 
> this is gonna be very ugly...

Come on, the CMake project will quickly implement all the Qt project
requirements.
And Qt Creator is about to have full blown support for it.

> What I do not understand is why the decision was qmake + cmake in the first 
> place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is 
> perfectly understandable to tap into wide CMake user base but why ditching 
> Qbs and not qmake? I wouldn't expect people would mourn qmake...

2 unmaintainable systems are better than one.

> Oh and on the point of CMake. Lets write a simple if statement as per docs:
> set(var1 "Hello")
> set(var2 "Hello")
> if(var1 EQUAL var2)
> message("They are equal")
> endif()
>
> Guess what, it prints NOTHING despite docs explicitly saying this should 
> work. Nothing will help, STREQUAL, MATCHES, dereferencing the arguments, 
> whatever. This will work:
>
> string(COMPARE EQUAL ${var1} ${var2} _cmp)
> if (_cmp)
> message("They are equal")
> endif()

Looks cool! :P Big improvement over qmake! Writing
Android/IOS/tvOS/embedded Linux/WinRT/whatever is about to get to the
next level, can't wait!

> Yeah, fortunately there is a wide knowledge how to work around this kind of 
> stuff. There are MANY other things like that that will make you cry when 
> writing even simple things in CMake's "language". Not to mention CMake is not 
> a build system, Qbs is.

Don't underestimate it, CMake is GNU m4 but better, like SVN was CVS but better.
Honestly, i never switched to git, I don't need a Ferrari to go fast,
you should see me on my bicycle. It even has a dynamo for the lights.

Come on, haven't you see the new build instructions
cmake -g Ninja
cmake --build . --target install --config release

Makes sense to me. Clear as mud! :)
--build and --target are not to be confused with GNU autotools
build/host/target, but the reader would have spotted that straight
away.
No need to explain '-g Ninja' (Capital N please), it makes sense to
first tell your build system, what build system it needs to use.
Ah yeah, BTW: "sudo cmake --build . --target install --config release".
Just to make sure that your build tree will be own by root b/c CMake
needs to go through the whole build phase before it dares evaluating
the install phase...
With CMake, you should drop your user account and log into X11R6 as
root, like the good old time, it works better with auto login tho.
For extra spice, try systemd's DHCP client.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Christian Gagneraud]

On 22 July 2018 at 00:42, Kevin Kofler  wrote:
> Bogdan Vatra via Development wrote:
>> Anyway IMHO is more important to have a clean, nice and easy to use syntax
>> and to be tooling friendly than 1.b.
>
> A custom build system is always a major pain point for distributions. A
> circular dependency (what Thiago's 1.b forbids) makes it particularly
> painful. How should we bootstrap new architectures or entirely new
> distributions if we cannot build Qt due to the circular dependency between
> Qt and its build tool? This is a showstopper.

How do you build gcc on Debian? Which compiler do you use? How do you
build the afore mentioned compiler in the first place?
Bootstrapping is a natural process in SW dev, and is and has always
been a long meander. Implementation details don't matter.
AFAIK, Debian cannot even be cross-compiled (Debian ports have never
been build this way)

CMake has a special bootstrapping mode, QMake has one, and any other
build tools (can) have their own, this includes Qbs, and many other..

IMHO, this self-contained, circular dependency discussion is moot.
As mentioned by Thiago himself, this is a non-problem, it can be
easily solved for most build system that are on the table.

Can we stop for a moment about self/circular dependency and bootstrapping?
Let's move on more serious topics.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Christian Gagneraud]

On 22 July 2018 at 14:05, Thiago Macieira  wrote:
> On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote:
>> -Ability to build external libraries from source or pull in binary
>> libraries
>
> This is not a feature. It's a misfeature.
>
> It's EXACTLY the reason our seniormost engineers spent three days trying to
> upgrade TensorFlow in Clear Linux. That's not your junior guy who only knows
> how to run "npn install". We're talking about people who had been building
> stuff on Linux years before you'd ever heard about Linux.

Clear Linux, hum? Are they re-inventing the wheel? And the hammer, the
nail, and the saw, what have you...

"Kata Container with Clear Linux"? What an obscure technology, and
what does it has to do with the Qt project and build system in
general?
So because Intel re-invents the wheel the Qt project shouldn't use
this or that? Honestly, I fail to follow you here.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Christian Gagneraud]

On 20 June 2018 at 03:33, Allan Sandfeld Jensen  wrote:
> Btw. Just for your information.
>
> I have attached a few random examples of what we can look forward too after
> running an auto-"beautifying" tool over our hand-formated Qt code. And these
> changes are NOT something we can configure out ouf of in clang-format, it is
> just cases where it can't do any better.

You can surround code with "// clang-format off" and "// clang-format on".
We've switched to clang-format in git hooks when clang-6 got out, and
it works well.



> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why waste energy supporting Python?

[Christian Gagneraud]

On 25 April 2018 at 13:41, d3fault  wrote:
> Supporting Python first class dilutes Qt, please don't. What's next,
> Qt for Java? It's one thing to collect community-developed bindings
> for various other languages into a single place... but something else
> entirely to pay an entire "team" of developers to work on what is
> essentially duplicated effort. That money could instead be spent on
> new Qt features and/or fixing the ever growing list of bugs
> (supporting Python first class will only add to that list of bugs).
> Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at

Maybe it's not the goal.

> least not without deploying a python interpreter (and we already have
> to deploy a JavaScript interpreter if we want to use QtQuick).
>
> Modern C++ has come leaps and bounds over recent years in improving
> code simplicity and safety (clang-tidy QtCreator integration FTW)...
> whereas afaik Python still crashes if you don't have your WHITESPACE
> perfectly organized bleh. Simply put, encouraging the use of

It doesn't crash, it errors out with an Exception that tell you what is wrong.
Messing with white space in python is like messing with curly braces in C++.

When you think about it, C++ for human is really stupid:
- The machine language dictates you to match your curly braces,
- and the human brain dictates you to keep your white spaces (visual
indentation).

Python has merged the 2 concepts into one. You should try.


> Python is the same thing as discouraging the use of Modern, Simple,
> and Safe C++.

Keep safe man, and sweet dreams...

Chris

>
> d3fault
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Christian Gagneraud]

Hi Thiago,

Thanks for the details, i'll switch to qt-interest. I've made progress
but still have a weird package conflict for QtWebEngine.

Chris

On 7 January 2018 at 03:27, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Saturday, 6 January 2018 09:21:35 -02 Christian Gagneraud wrote:
>> > Regular configure -platform linux-g++-32 && make. There's nothing special.
>>
>> Well, thanks for the tip!
>
> To be clear, this is my config.opt (newlines replaced by spaces). I have other
> options, but nothing special:
>
> -opensource -confirm-license -developer-build -system-libjpeg -system-libpng
> -system-sqlite -reduce-relocations -xcb -pch -dbus-runtime -qtlibinfix .32
> -nomake tests -nomake examples -platform linux-g++-32-optimised
> -qtnamespace QtI386 -release
>
> As you can see, this is also my namespace-testing build. As for linux-g++-32-
> optimised, it's basically adding -march=native -mno-rdrnd to QMAKE_CFLAGS.
>
>> The main issue is dependencies, the best document I found is an ICS blog
>> post: https://www.ics.com/blog/how-compile-qt-source-code-linux
>>
>> But that covers only 32bits build on 32bits host or 64bits build on 64
>> bits host.
>
> $ rpm -qa --qf "%{NAME}\\n" *-devel-32bit
> libstdc++-devel-32bit
> libICE-devel-32bit
> libxkbcommon-devel-32bit
> libjpeg62-devel-32bit
> xcb-util-wm-devel-32bit
> libX11-devel-32bit
> libSM-devel-32bit
> libXext-devel-32bit
> libxcb-devel-32bit
> libpng16-devel-32bit
> xcb-util-image-devel-32bit
> dbus-1-devel-32bit
> glibc-devel-32bit
> xcb-util-keysyms-devel-32bit
> libXi-devel-32bit
>
>> When I asked my question a few month ago, it was all about how to
>> install all the 32 bits (dev) packages on a 64 bits Linux machine
>> without having to resort to "dirty hacks", and so far i've been
>> unlucky, and nobody was able to give me any hints (not blaming anyone
>> here)
>>
>> So may I rephrase my question?
>> Do you have the magic list for apt/zypper that would allow to build
>> Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine?
>
> Try installing my listing above. It should be a good start.
>
> It's probably not complete: you may need some more 32-bit tools that aren't
> *-devel-32bit and you need some 64-bit tools too.
>
>> >> Or maybe we're not talking about the same thing. I'm not even sure
>> >> what the Qt Company means by "Supported until Mar. 16, 2019" on
>> >> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6).
>> >> What I'm sure of, is that i cannot download Qt-5.6 binaries for
>> >> Linux-x86_32 (commercial or opensource).
>> >
>> > That's Qt 5.6's support lifetime. It's a Long Term Support release, so
>> > we'll keep adding patches and fixes to it until that date. That includes
>> > all compilers and platforms that were supported at the time of the
>> > release, however difficult it may get for us next year to build.
>>
>> Just a wee reminder that "support" doesn't mean "full support".
>> Remember how we ended up on the gcc (or binutils?) bug board because
>> the QThread test suite was failing?
>
> Right, there are levels. There are platform combinations that are tested by
> the main CI; there are others that are tested only by the qt5.git CI. All of
> those are confirmed to be compiling and working at any release. Then there are
> those we are pretty confident on, but don't always check.
>
> Here's the link for the last qt5 5.9 integration:
> https://testresults.qt.io/coin/integration/qt/qt5/tasks/1515209498
>
> As you can see, there are a couple of 32-bit builds:
>  * Android 32-bit x86
>  * Integrity 32-bit ARM
>  * Linux 32-bit ARM
>  * QNX 32-bit ARM and x86
>  * Windows 32-bit x86 (MinGW and MSVC)
>
> So even though a 32-bit x86 build for regular Linux is missing, we should be
> pretty confident it works. It would only be failing if we had some x86-
> specific Linux-specific (non-Android) code and I don't think we do.
>
> We have x86-specific code, but it's cross-OS and/or 64-bit capable too: the
> only thing I can think of that comes closest is the early CPUID detection,
> since all 64-bit CPUs have CPUID and the assembly is compiler dependent, but
> even then it's code we don't need to modify and it does get compiled on for
> both Android and MinGW.
>
>> For me, it's quite simple:
>> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt
>> binaries = No (opensource/commercial) support.
>
> No CI, see above.
> No binaries, build from sources.
> No support, sorry, I can't comment.
>
&

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Christian Gagneraud]

On 5 January 2018 at 15:11, Thiago Macieira  wrote:
>> I wish too, i could target Linux-x86_64, but i cannot. This codebase
>> currently builds for WINTEL32 and Linux/ARM32, it used to be built for
>> a Geode or VIA proc, some time ago, with Qt-4.x
>
> The fact that you mention Geode and VIA means it's *old*.

Yes parts of the code base are vey old (VIA/Geode is just
ghost code), certainly older than Qt itself...

But that was not my point:
I don't have a HW problem, I have a SW problem. I cannot link against
Qt-x86_64 b/c i cannot build my codebase for x86_64.
I will run Qt/32bits on a 64 bits machine. This is my (sad) life, period.

>> > I've never had a problem, but I confess I don't try to build all of Qt. I
>> > build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The
>> > 32-bit build is only for qtbase, once every couple of months. For
>> > example, I still need to do the benchmarking for the new qHash function
>> > in 32-bit, which I find to be a poor use of my time so I haven't done
>> > yet.
>> > [*] not including qtwebengine. I've never built that.
>>
>> You told me so a few month ago, and I switched to OpenSuse since then,
>> but i still had issues, and the only way to get around was to break
>> the host distro (force-install some dev packages, 'ln -sf' SO here and
>> there, ...)
>> Please share your script if you have some.
>
> Regular configure -platform linux-g++-32 && make. There's nothing special.

Well, thanks for the tip!

The main issue is dependencies, the best document I found is an ICS blog post:
https://www.ics.com/blog/how-compile-qt-source-code-linux

But that covers only 32bits build on 32bits host or 64bits build on 64
bits host.

When I asked my question a few month ago, it was all about how to
install all the 32 bits (dev) packages on a 64 bits Linux machine
without having to resort to "dirty hacks", and so far i've been
unlucky, and nobody was able to give me any hints (not blaming anyone
here)

So may I rephrase my question?
Do you have the magic list for apt/zypper that would allow to build
Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine?
I don't care about Redhat vs Suse vs Debian vs ... I just need to
generate a 32 bits archive of Qt that can be used on a 64 bits Linux
machine.

>> Or maybe we're not talking about the same thing. I'm not even sure
>> what the Qt Company means by "Supported until Mar. 16, 2019" on
>> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6).
>> What I'm sure of, is that i cannot download Qt-5.6 binaries for
>> Linux-x86_32 (commercial or opensource).
>
> That's Qt 5.6's support lifetime. It's a Long Term Support release, so we'll
> keep adding patches and fixes to it until that date. That includes all
> compilers and platforms that were supported at the time of the release,
> however difficult it may get for us next year to build.

Just a wee reminder that "support" doesn't mean "full support".
Remember how we ended up on the gcc (or binutils?) bug board because
the QThread test suite was failing?

For me, it's quite simple:
No (opensource/commercial) Qt CI = No (opensource/commercial) Qt
binaries = No (opensource/commercial) support.

If you don't build and test on a regular basis, it can break at any
moment without anyone noticing (and it did happened at least once)

Chris

PS: In case you think I'm ranting for free here, i would like to say
(again) that I think Qt is a great piece of (opensource/commercial)
SW, and big thumb up to anyone behind this, The Qt Project, The Qt
Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or
corporate.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [OT] Re: 32bit linux build of qt5.10.0 w/ webengine

[Christian Gagneraud]

On 5 January 2018 at 15:11, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Thursday, 4 January 2018 23:40:40 -02 Christian Gagneraud wrote:
>> Neatpick: AVX itself doesn't require billions of transistors, the
>> first intel proc to require more than a billion transistor are 4 and 6
>> cores i7.
>> https://en.wikipedia.org/wiki/Transistor_count
>
> Fair enough. The billions are usually due to expanded L3 caches, not the CPU
> itself. I was exaggerating.

or L2, or L1... it all depends on size. Static RAM usually requires 4
transistors per bit, and dynamic RAM only one (on average)

1MB of cache => 4 * 1 * 8 * 1024 * 1024 = 33.5 millions transistors

The more cores on a die, the more L3 cache you need... And nowadays,
50MB of L3 is not that crazy...

This is certainly wrong (i'm not very aware of the latest
technologies), but it should be a "fair" guesstimate.

> Still, AVX and AVX2 are considerable die size (don't know how much).

I've googled for half an hour to find this information and finally
gave up. Since you work for Intel, maybe you could ask one of your
colleague, that's an interesting bit of information.
Since SSE and AVX are just sub-components of a specialised ALU/FPU, I
wouldn't be surprised if they require less than a few thousand
transistors each (they "just" implement specialised operations), and
die size contribution is certainly less than 0.01 % (Wild guess
again).
Another noob question would be how much of them is actually hard-wired
operation vs instruction implemented via ROM microcode.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Christian Gagneraud]

On 5 January 2018 at 12:22, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Thursday, 4 January 2018 20:52:40 -02 Christian Gagneraud wrote:
>> On 5 January 2018 at 03:16, Kevin Kofler <kevin.kof...@chello.at> wrote:
>> > Thiago Macieira wrote:
>> >> In particular: -no-sse2.
>> >>
>> >> If you use that option, that means you're optimising for Pentium III and
>> >> earlier, not Pentium 4. All Pentium 4 processors have SSE2.
>>
>> I was looking at LEDE (a fork/merge of OpenWRT) recently, and their
>> 'i386' build actually target Pentium 4, which is i686++
>> See https://lede-project.org/docs/instructionset/i386_pentium4
>
> I don't know what devices LEDE is targetting, but we can break down 32-bit x86
> into four segments:

It's not just about what hardware you target, in my case, i cannot
build the codebase in 64 bits, simply because the code is not 64-bits
ready (mainly due to legacy old/complicated components): Not only the
code base is full of 32 vs 64 issues, but it actually doesn't build at
all, and fixing it is not an easy job and not a priority (yet).
I wish too, i could target Linux-x86_64, but i cannot. This codebase
currently builds for WINTEL32 and Linux/ARM32, it used to be built for
a Geode or VIA proc, some time ago, with Qt-4.x

And thinking about that, why is it a pain to maintain Linux-x86_32
when you have to maintain Linux-_32 and -*_32?
>From http://doc.qt.io/qt-5/supported-platforms.html, Qt-5.10 supports
the following 32 bits platforms:
- Android-armv7
- WatchOS-armv7
- Windows-{7,8.1,10}-x86_32
- Windows-UWP-{x86_32,armv7}
- Boot2Qt-{armv7,x86_32}
- Qnx-{armv7,x86_32}

Please note the Boot2Qt-x86_32, which is a weird case as it is an
"Embedded Linux" for x86_32 (Yocto).
The only reason for supporting "Embedded Linux" for x86_32 and not
"Desktop Linux" for x86_32 is, I guess, CI workload.

> Obviously, my employer would like nothing better than we start targetting 2
> and 3. Those billions of transistors you have in your processor for AVX should
> get used to improve performance, not just produce heat.

Neatpick: AVX itself doesn't require billions of transistors, the
first intel proc to require more than a billion transistor are 4 and 6
cores i7.
https://en.wikipedia.org/wiki/Transistor_count

This slides are interesting as well,
https://www.inf.ethz.ch/personal/markusp/teaching/263-2300-ETH-spring12/slides/class03.pdf.
L2/L3 cache is what takes the most space.

>> I have been fighting with x86_32 build of Qt too, I never managed to
>> build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly
>> the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a
>> docker container.
>
> I've never had a problem, but I confess I don't try to build all of Qt. I
> build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The 32-bit
> build is only for qtbase, once every couple of months. For example, I still
> need to do the benchmarking for the new qHash function in 32-bit, which I find
> to be a poor use of my time so I haven't done yet.
> [*] not including qtwebengine. I've never built that.

You told me so a few month ago, and I switched to OpenSuse since then,
but i still had issues, and the only way to get around was to break
the host distro (force-install some dev packages, 'ln -sf' SO here and
there, ...)
Please share your script if you have some.

>
>> You're not (and I'm not either) the first one to report problems with
>> building Qt on x86_32 Linux recently.
>> Linux32 is officially not supported any more, and I think it is a mistake.
>
> Yes, it is. Please report issues so we can fix them.

I might do it once i'm back on my 32 bits build task.
But the difficulty is to create a "good" ticket. If I do it right now,
the issue would look like:
"I followed https://wiki.qt.io/Building_Qt_5_from_Git and i cannot
build Qt-5.6 for x86_32 on a "common" Linux distro (x86_32/64)"

With all due respect to Wiki contributors,
https://wiki.qt.io/Building_Qt_5_from_Git looks like a giant mess,
with the usual 200 Linux distro specifics, outdated and unorganised
information, ...


>> Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong.
>
> Agreed. There are people who need it. Very few, but they exist.

What do you base your "very few" on?
I would be interested to see the download stats of Qt-5.5 for Linux-32.

>> And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6
>> (LTS) was not a user/client friendly move either.
>
> Since it wasn't dropped, the point is moot.

Linux-Desktop-x86_32 was dropped with Qt-5.6. The last Qt version to
support it was Qt-5.5, and Qt-5.5 has now disappear from
http://download.qt.io/official_releases

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Christian Gagneraud]

On 5 January 2018 at 03:16, Kevin Kofler  wrote:
> Thiago Macieira wrote:
>> In particular: -no-sse2.
>>
>> If you use that option, that means you're optimising for Pentium III and
>> earlier, not Pentium 4. All Pentium 4 processors have SSE2.

I was looking at LEDE (a fork/merge of OpenWRT) recently, and their
'i386' build actually target Pentium 4, which is i686++
See https://lede-project.org/docs/instructionset/i386_pentium4

I have been fighting with x86_32 build of Qt too, I never managed to
build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly
the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a
docker container.

You're not (and I'm not either) the first one to report problems with
building Qt on x86_32 Linux recently.
Linux32 is officially not supported any more, and I think it is a mistake.
Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong.
And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6 (LTS)
 was not a user/client friendly move either.

>>
>> More importantly, SSE2 is *MANDATORY* for 64-bit builds. You may not turn
>> it off. The errors you are getting are related specifically to this
>> option. So are you sure you're building 32-bit?
>
> In addition, QtWebEngine always requires SSE2 no matter how you configure
> Qt. Chromium stopped supporting machines without SSE2 a few years ago.
>
> There is a huge patch (from me) to allow building for non-SSE2 i686 machines
> in the Fedora qt5-qtwebengine package, but that patch is completely
> unsupported by upstream.

I might investigate Fedora 24, which ships Qt-5.6.

Chris

>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 18/10/17 21:35, Kevin Funk wrote:

On Monday, 16 October 2017 22:48:06 CEST Christian Gagneraud wrote:

I think my questioning was legit, even if the style was far from perfect.


Right, let me excuse myself as well for the strong wording.


Hi Kevin,

"Sweet as" as they say here in New Zealand, I would like to apologise 
too, i should not have said what I said, the way I did. I didn't mean to 
be offensive, never.



Let's calm down, go back to topic and have a beer together on the next QtWS.


I sincerely wish it will happen.

I will hopefully soon start watching some of the talks, now there are 
on-line - thanks to the The Qt Company [1].
I am still looking for the slides, at work we sometimes do "talk about 
the talks", ideally people reports about what they've seen at the event. 
But sometimes one just report about the "slides of the event", it's OK 
too, any digested piece of information is always welcome! ;)
Even if you're the lucky one to have been there, you still need the 
original slides you want to quote.


Chris

[1] http://blog.qt.io/blog/2017/10/24/qt-world-summit-2017-recordings/




Cheers,
Kevin


Anyway, now I know the answer thanks to people's responses.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt installation prefix path issue

[Christian Gagneraud]

On 18/10/2017 8:08 pm, "Thiago Macieira"  wrote:

[moving to the interest mailing list; please drop development@ when
replying]

On Tuesday, 17 October 2017 23:38:24 PDT bhaskar kotha wrote:
> How to configure Qt so that Qmake should not take absolute path.

That's not possible. You can't move Qt: you have to decide where it's going
to
be the moment you configure.


It is actually possible, but it's far from trivial. Boot2qt Yocto SDK is
doing exactly this.
I don't have references right now, but the answer is in boot2qt git
repositories.

Basically you need to patch the binaries after relocation.

Chris




Also, please upgrade to 5.6, 5.9, 5.10. Qt 5.4 is not supported.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 17/10/2017 11:27 PM, Jake Petroules wrote:

We both want to solve the same problems, but I'm not sure exactly
what you mean here about how building Qt with Qbs is a trap and that
we should not "leak".


The trap:
From reading your comments, I had the feeling that you're thinking that 
building Qt with Qbs will help having a better Qt/Qbs integration when 
building the user's project.
I think it's dangerous, the 3 things are orthogonal: building Qt with 
Qbs, Qbs having a build dependency on Qt, and user using Qbs to build 
their Qt-dependent (or not) own projects.


The leak:
Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt.
QtC suffers from that as well, I wrote an email about that, when i 
realised that QtC was indirectly executing the cross-compiler defined in 
qmake's mkspec and found on the PATH instead of using the one defined in 
the QtC kit. This is rather scary.




My point was that the Qbs module files to describe the various Qt
libraries must come from somewhere - either as a probe-based module
within Qbs, an installation of Qt itself, or a combination. If we
rely solely on probe-based modules within Qbs, then we need a way to
dynamically generate modules at runtime (since we can't know about Qt
modules which don't yet exist), which is currently not possible. This
could end up being useful in the general case too, or maybe it isn't,
but like any major architectural decision, it needs time and
thought.


Thanks for explaining, maybe this means that Qt should not be a Qbs 
module. Or it should be a "container" module that gets populated by a probe.
The handling of a product dependency on, say, Qt.Widgets, should not be 
different than a product dependency on boost or whatever library.

Qbs doesn't have/need a boost module.

Now I understand that Qt is more than the sum of it's libraries/modules, 
there are moc, qdoc, qrc, uic, Qml, ... too. And this make the job harder.





We (at work) all want this, the only problem with qbs are: -
stability (not blaming qbs, I knew I picked up an on going effort) 
- Qbs != Qt


Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling
of Qbs and Qt is a strength, and it seems like you already agree with
that...


I agree that it would be a strength, if Qbs and Qt were not tightly coupled.

My understanding is that Qbs can be used on non Qt-dependent projects 
(bare-metal or not), nice. But this doesn't make Qbs completely 
decoupled from Qt, because as soon as I need Qt for my project, the 
whole "q" kitchen sink get pulled in. This is not a Qbs-specific problem 
tho.





- CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned
embedded Linux builds w/o relying on qmake?

I have hope, of all the cross-build systems I have used in the past
15 years, none have been satisfactory, could qbs make a break
through?


Hey, positive *and* negative (but constructive) feedback is always
welcome. :)


This was not even negative, i am not satisfied with all the build 
systems I've tried so far, but it's OK, such is life! :)


What I like with Qbs is the flexibility and its structured yet dynamic 
language (Qml-ish).
But I'm having scalability and performance issues, that's another story 
that i will report on the Qbs mailing list once i'm back on my Qbs stuff.



Chris

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 17/10/2017 9:30 pm, "Jake Petroules" <jake.petrou...@qt.io> wrote:



> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud <chg...@gmail.com> wrote:
>
> On 17/10/2017 7:52 pm, "Jake Petroules" <jake.petrou...@qt.io> wrote:
>
> > On Oct 16, 2017, at 3:34 PM, jeandet <alexis.jean...@member.fsf.org>
wrote:
> >
> > I have the feeling that a Qt build system will always force the users
> > to choose between another tool they know but where the Qt support might
> > not be the best and a Qt focused tool with a good Qt support but they
> > will have to deal with external libs and might suffer corner cases.
>
> Indeed, which is why Qbs aims to solve both of those problems. Excellent
Qt support and excellent non-Qt support. Choose both.
>
> > As Qt user I started with qmake, I enjoyed writing projects with qmake
> > then I switched to CMake to make easier usage of non Qt libs and
> > config. Finally I switched to Meson and won't go back to CMake. I'm not
> > sure I would switch to Qbs unless it gets less Qt focused.
>
> You should watch my World Summit talk when it's available on YouTube. :)
>
> One of the key points I talked about and which is very important is that
Qbs is NOT Qt-focused. Is it meant to be a completely generic build tool
which just happens to ship with out-of-the-box Qt support. I've been
working on Qbs for 5 years and have made close to 1000 changes, and for all
of those 5 years I actually haven't worked on the Qt support very much at
all.
>
> Well, from a qbs user POV, Qt is still a privileged component (not
talking about qbs own build dependency here). And "qbs-setup-qt" is the
curlprint.
>
> I don't see why this is needed (in an ideal world). This is actually a
qmake backdoor into qbs. Or call it a high coupling hotspot if you wish.
> Can qbs be used to build a qt dependent project without a qt profile? I
don't think so.
>
> Qt should be detected the same way as any other user's project dependency
(probe link and include specifics), instead qmake is used as a proxy.
>
> In that respect cmake (or any other build system) got it right, qbs got
it wrong.
>
> On Linux, qt should be detected using qbs probe and package-config,
period.
>
> I never liked qbs profile, they are awkward to manage in CI.
>
> Once you have a toolchain and a Qt profile everything is cool, but if you
start from a virgin install (eg. generic docker image), things look bad. I
guess this is a distro integration problem. But "distro" is Linux specific.
Mac and windows are far beyond.

I never liked profiles either, and we have been moving away from them as a
hard requirement. On macOS and Linux you can now build projects without a
profile at all (there might be a bug or two with certain MSVC installations
at the moment) if you don't use Qt.

Getting rid of qbs-setup-qt will take some time, and we still need to find
a solution to the problem of having to hardcode the list of all possible Qt
modules (although when Qt itself is built with Qbs this problem may simply
go away by definition). In fact you could argue right now that Qt is NOT a
privileged component since it requires special additional setup to use it.


With all due respect may I suggest that building qt with qbs is actually a
trap, please don't rely on that to solve your user's problems.
Qt is your toolkit, not mine. You should not leak. (No offense. I'm just
sharing my experience, but it seems I need to justify myself if I don't
want to be labelled "what are you smoking", I'm getting really pissed off
about that)

We have a couple of code bases, one is embedded Linux with Qt (UI/user
facing), others are auxiliary microcontroller and DSP running bare metal
c++.

Qbs could be used for all these projects, I don't see any big technical
difficulties.

All of these projects could benefit from qbs and the clang compilation
database plugin I wrote (yeah I can be egocentric too), everyone is asking
for auto SQA.

We (at work) all want this, the only problem with qbs are:
- stability (not blaming qbs, I knew I picked up an on going effort)
- Qbs != Qt
- CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned embedded
Linux builds w/o relying on qmake?

I have hope, of all the cross-build systems I have used in the past 15
years, none have been satisfactory, could qbs make a break through?

Chris




But don't mistake this as a "fundamental design flaw", it's always been a
temporary solution. We have top men working on it right now... top men.

>
> Chris
>
>
>
> > I still miss the point of making a dedicated build system instead of
> > contributing to more general build systems like Meson or even CMake.
>
> Qbs is just as general as both of those, and in my opinion, even more so.
Please, try it out - you may be surprised

Re: [Development] Future of QBS

[Christian Gagneraud]

On 17/10/2017 7:52 pm, "Jake Petroules"  wrote:


> On Oct 16, 2017, at 3:34 PM, jeandet 
wrote:
>
> I have the feeling that a Qt build system will always force the users
> to choose between another tool they know but where the Qt support might
> not be the best and a Qt focused tool with a good Qt support but they
> will have to deal with external libs and might suffer corner cases.

Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt
support and excellent non-Qt support. Choose both.

> As Qt user I started with qmake, I enjoyed writing projects with qmake
> then I switched to CMake to make easier usage of non Qt libs and
> config. Finally I switched to Meson and won't go back to CMake. I'm not
> sure I would switch to Qbs unless it gets less Qt focused.

You should watch my World Summit talk when it's available on YouTube. :)

One of the key points I talked about and which is very important is that
Qbs is NOT Qt-focused. Is it meant to be a completely generic build tool
which just happens to ship with out-of-the-box Qt support. I've been
working on Qbs for 5 years and have made close to 1000 changes, and for all
of those 5 years I actually haven't worked on the Qt support very much at
all.


Well, from a qbs user POV, Qt is still a privileged component (not talking
about qbs own build dependency here). And "qbs-setup-qt" is the curlprint.

I don't see why this is needed (in an ideal world). This is actually a
qmake backdoor into qbs. Or call it a high coupling hotspot if you wish.
Can qbs be used to build a qt dependent project without a qt profile? I
don't think so.

Qt should be detected the same way as any other user's project dependency
(probe link and include specifics), instead qmake is used as a proxy.

In that respect cmake (or any other build system) got it right, qbs got it
wrong.

On Linux, qt should be detected using qbs probe and package-config, period.

I never liked qbs profile, they are awkward to manage in CI.

Once you have a toolchain and a Qt profile everything is cool, but if you
start from a virgin install (eg. generic docker image), things look bad. I
guess this is a distro integration problem. But "distro" is Linux specific.
Mac and windows are far beyond.

Chris



> I still miss the point of making a dedicated build system instead of
> contributing to more general build systems like Meson or even CMake.

Qbs is just as general as both of those, and in my opinion, even more so.
Please, try it out - you may be surprised!
--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 16 October 2017 at 21:40, Kevin Funk <kevin.f...@kdab.com> wrote:
> On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote:
>> On 14 October 2017 at 04:22, Jean-Michaël Celerier
>>
>> <jeanmichael.celer...@gmail.com> wrote:
>> >> nobody is going to port Qt to CMake (if you disagree start a new thread)
>> >
>> > https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8
>>
>> I would resume this post as "I love CMake, CMake is the only way.
>> You're all wrong."
>> This post doesn't explain anything, doesn't gives any analysis, no
>> comparison, no argument whatsoever, nothing.
>>
>> How many people had the same reaction when clang started?
>> Nowadays, clang is actually far superior to gcc, it brought tooling
>> like we would never have dared to dream of .
>>
>> Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>> SVN was "CVS in better", git is a completely different approach to
>> SCM, SVN is now a zombie.
>>
>> "Not reinventing the wheel" has to be balanced with "innovation".
>>
>> IMHO, Qbs' great potential is the "completely new approach".
>> Qbs would be a failed attempt if it was "CMake in better".
>>
>> I think it's worth thinking about that, and be critical instead of
>> being blind nay-sayer.
>>
>> >> a complete CMake build for Qt was already contributed upstream (quite
>> >> some
>> >> time ago) .. and rejected ..
>>
>> It would be interesting to know why. Oswald said "we (...) are
>> strongly biased against a
>> cmake-based solution", but didn't give any reason/justification (Or I
>> missed it).
>>
>> Did this CMake port cover all the features provided by qmake?
>> Did this CMake port provide all the configuration needed by Qt, on all
>> the supported platform?
>> Could the Qt CI switch to CMake then?
>>
>> And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
>> Systems/CMake" thread?
>> Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
>> when it comes to evaluating  new build systems for Qt? or is it an
>> hijack attempt, an insider infiltration?
>
> This little 'misunderstanding' has been clarified in sub-threads already, but
> I still need to chime in here...
>
> To paraphrase BogDan: 'What are you smoking?'

I find the original statement and your paraphrasing quite offensive,
disrespectful and absolutely useless.
There is no need for such things.

It's easy to quote a message partially and attack people.
You have omitted 'Or is it pure timing coincidence, and Kevin Funk is
actually a "build
system*s* guy"?' from your quote above.
I think my questioning was legit, even if the style was far from perfect.

Anyway, now I know the answer thanks to people's responses.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Review for new widget module [your advices are needed]

[Christian Gagneraud]

Few days ago, should be easy to find on mailing list archives
Sorry on my phone right now.
Go to October arch.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 16/10/2017 7:31 pm, "BogDan Vatra" <bog...@kdab.com> wrote:

On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote:
> On 16 October 2017 at 15:42, Kevin Kofler <kevin.kof...@chello.at> wrote:
> > Christian Gagneraud wrote:
> >> I would resume this post as "I love CMake, CMake is the only way.
> >> You're all wrong."
> >> This post doesn't explain anything, doesn't gives any analysis, no
> >> comparison, no argument whatsoever, nothing.
> >
> > It makes one important point (and elaborates it to great lengths):
> > developer familiarity. Even if QBS were actually a lot better than CMake
> > (something I am also very sceptical about), it would still be
universally
> > hated simply because it is not what developers (and distribution
> > packagers!) know.
> Universally, really? In your world maybe, not in mine.
>
> Anyway, I think the discussion is turning sterile, at least for me.
> You are free to make your own choice, and so am I.
>
> In case my wording sounded harsh, I would like to let you know that I
> am genuinely happy for you to be in charge of CMake support, I mean
> it.
>

"Kevin Kofler" != "Kevin Funk" ...


!= "Kevin Ottens"

This remind me at work, we're 3 Chris within 3 meters of each other, in the
same team! Everytime someone comes around and say "hey Chris" loud enough,
3 heads turn around funny at first but it gets annoying with time...

Anyway I knew I was not talking to Kevin Ottens, glad to hear from you
Kevin O.! You've put a big smile on my face!
Back at the time when I worked with Kevin O (hope you don't mind) I was an
electronic engineer, saying stuff like "I love Gnome, Gnome is the only
way, you're all wrong".

And then I tried GTK... ;) I had to wash my hands for 3 hours! ;)

I'm glad to have opened up, strengthen my C++ and discovered Qt and KDE.
Although I love QtC, I still think that emacs is way superior... Lol!
Seriously, can you do VHDL with QtC? ;)

Things change, and I feel good.

Chris





Whatever you're smoking, I want some too ;-) !

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Review for new widget module [your advices are needed]

[Christian Gagneraud]

>From an end user point of view, i think it's a great idea but I think it
conflicts with Qml.
At work we have our own set of highly customised widgets, for embedded
devices, it simply works, no need (yet) for Qml.

I would be interested to see your work and give my opinion if it can help.

Full disclosure: I've never been a reviewer, but went through the process
as a contributor a couple of times (qt or not).
Don't expect a +1 from me as I'm not a Qt Project member.

Thiago sent a link recently to a blog post regarding code review process.
Step 1 is all about the idea itself.

Chris

--
Answering from my phone, please excuse my brievity.

On 16/10/2017 6:53 pm, "iman ahmadvand"  wrote:

No one interested ?

On Sat, Oct 14, 2017 at 11:03 AM, iman ahmadvand 
wrote:

> Hi everyone.
>
> Before I send some code base on codereview and decide whether my
> implementation meets the requirements,  I  just want to know your thoughts
> about design decision for the new module I’m trying to add to Qt Play
> ground.
>
> So as you probably guessed my plan is to developing a new widget module
> (which I’m going to name it MaterialWidgets) for Qt, a modern collection of
> widgets that should have the same look and feel on all platforms. All the
> GUI parameters and styles are taken from material style guide line(
> https://material.io/guidelines). You can think of MaterialWidgets as the
> MaterialStyle in QML design but in pure C++.
>
> Here is a few things to clarify:
> 1.Why someone need to use material styled widgets in Qt?
> There are a bunch of app out there that need this to be available on
> widgets so they can easily take the benefit of newly added widget set.
>
> 2.Why a new widget set? why just no to use already built-in styles?
> Material widgets are going to be a special set of controls which has
> animations by default, and GUI parameters are differs from built-in
> QtWidgets. for an example material style has a component called
> ContinuousSlider which has two sub component Thumb and Track and two state
> On(value == 0) and Off(value != 0) and a color palette for each state, so
> doing this with styles can't be done unless we change the enumerators and
> maybe more!
>
> 3.Are every thing from scratch ?
> No. not at all.
> I just make some changes in inherited classes from built-in QtWidgets
> (basics AND abstracts), so the logics behind those widgets should be the
> same.
>
> A note for animation implementation  in MaterialWidgets:
> A class called Animation is responsible for animating those widgets, the
> simple idea behind that is to have a target object (which mostly is a
> widget) associated with animation objet and after every refresh in
> animation (updateCurrentValue) we should make an update of type
> StyleAnimationUpdate in target widget so it makes the code base more
> cleaner.
>
> Here you can see just a review version of module (just ContinuousSlider is
> included): ​
>  qtmaterialwidgets.zip
> 
> ​
>
> I'm ready to hear your advices and thoughts.
>
> Regards
> Iman.
>


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 16 October 2017 at 15:42, Kevin Kofler <kevin.kof...@chello.at> wrote:
> Christian Gagneraud wrote:
>> I would resume this post as "I love CMake, CMake is the only way.
>> You're all wrong."
>> This post doesn't explain anything, doesn't gives any analysis, no
>> comparison, no argument whatsoever, nothing.
>
> It makes one important point (and elaborates it to great lengths): developer
> familiarity. Even if QBS were actually a lot better than CMake (something I
> am also very sceptical about), it would still be universally hated simply
> because it is not what developers (and distribution packagers!) know.

Universally, really? In your world maybe, not in mine.

Anyway, I think the discussion is turning sterile, at least for me.
You are free to make your own choice, and so am I.

In case my wording sounded harsh, I would like to let you know that I
am genuinely happy for you to be in charge of CMake support, I mean
it.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 15 October 2017 at 23:23, Jake Petroules <jake.petrou...@qt.io> wrote:
>
>
>> On Oct 15, 2017, at 11:20 AM, Christian Gagneraud <chg...@gmail.com> wrote:
>>
>> On 14 October 2017 at 04:22, Jean-Michaël Celerier
>> <jeanmichael.celer...@gmail.com> wrote:
>>>> nobody is going to port Qt to CMake (if you disagree start a new thread)
>>>
>>> https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8
>>
>> I would resume this post as "I love CMake, CMake is the only way.
>> You're all wrong."
>> This post doesn't explain anything, doesn't gives any analysis, no
>> comparison, no argument whatsoever, nothing.
>>
>> How many people had the same reaction when clang started?
>> Nowadays, clang is actually far superior to gcc, it brought tooling
>> like we would never have dared to dream of .
>>
>> Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>> SVN was "CVS in better", git is a completely different approach to
>> SCM, SVN is now a zombie.
>>
>> "Not reinventing the wheel" has to be balanced with "innovation".
>>
>> IMHO, Qbs' great potential is the "completely new approach".
>> Qbs would be a failed attempt if it was "CMake in better".
>>
>> I think it's worth thinking about that, and be critical instead of
>> being blind nay-sayer.
>>
>>>> a complete CMake build for Qt was already contributed upstream (quite some
>>>> time ago) .. and rejected ..
>>
>> It would be interesting to know why. Oswald said "we (...) are
>> strongly biased against a
>> cmake-based solution", but didn't give any reason/justification (Or I
>> missed it).
>>
>> Did this CMake port cover all the features provided by qmake?
>> Did this CMake port provide all the configuration needed by Qt, on all
>> the supported platform?
>> Could the Qt CI switch to CMake then?
>>
>> And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
>> Systems/CMake" thread?
>> Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
>> when it comes to evaluating  new build systems for Qt? or is it an
>> hijack attempt, an insider infiltration?
>> Or is it pure timing coincidence, and Kevin Funk is actually a "build
>> system*s* guy"?
>
> As I said in my QtWS talk, we recognize that people must be given a choice of
> build system for their own projects, and for that reason we will continue to
>  support and provide CMake modules for Qt libraries.
>
> Since Kevin's been doing the work of maintaining these modules anyways, it
> makes sense that he officially be labeled Maintainer. Ossi is still chief
> maintainer of build systems generally, Kevin is simply being nominated as a
> sub-maintainer for the CMake build systems area just as I am a sub-maintainer
> of the Apple Platforms (macOS/iOS) build systems area. This has nothing to
> do with Qbs or Qt's use of it.
>
> André actually asked me if I was OK with him nominating Kevin, given my role
>  in driving Qbs, which of course I am for the above stated reasons. :)

Cool, glad to hear everything went smoothly. I didn't realise the
issue about internal build system in use vs exported build system
support.

+1 for Kevin! ;)

>> I have no power of decision, so i will accept any.
>>
>> Nonetheless, I think it would be a mistake to choose a build system
>> over the other because "I love Xyz, Xyz is the only way. You're all
>> wrong."
>>
>> Who knows, maybe the answer to "Which new build system for Qt" could
>> be neither CMake, neither Qbs.
>
> We've already decided internally that we want to push Qbs as the new build 
> tool, and I have no doubt that the community will agree.

I hope you all the best, please get rid of qmake.

qmake is a real pain, and it gets even worth when cross-compiling.
It's leaking everywhere, even QtCreator suffers from that.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Gagneraud]

On 14 October 2017 at 04:22, Jean-Michaël Celerier
 wrote:
>> nobody is going to port Qt to CMake (if you disagree start a new thread)
>
> https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8

I would resume this post as "I love CMake, CMake is the only way.
You're all wrong."
This post doesn't explain anything, doesn't gives any analysis, no
comparison, no argument whatsoever, nothing.

How many people had the same reaction when clang started?
Nowadays, clang is actually far superior to gcc, it brought tooling
like we would never have dared to dream of .

Same goes with SVN vs git, now (almost) everyone have given up with SVN.
SVN was "CVS in better", git is a completely different approach to
SCM, SVN is now a zombie.

"Not reinventing the wheel" has to be balanced with "innovation".

IMHO, Qbs' great potential is the "completely new approach".
Qbs would be a failed attempt if it was "CMake in better".

I think it's worth thinking about that, and be critical instead of
being blind nay-sayer.

>> a complete CMake build for Qt was already contributed upstream (quite some
>> time ago) .. and rejected ..

It would be interesting to know why. Oswald said "we (...) are
strongly biased against a
cmake-based solution", but didn't give any reason/justification (Or I
missed it).

Did this CMake port cover all the features provided by qmake?
Did this CMake port provide all the configuration needed by Qt, on all
the supported platform?
Could the Qt CI switch to CMake then?

And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
Systems/CMake" thread?
Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
when it comes to evaluating  new build systems for Qt? or is it an
hijack attempt, an insider infiltration?
Or is it pure timing coincidence, and Kevin Funk is actually a "build
system*s* guy"?

I have no power of decision, so i will accept any.

Nonetheless, I think it would be a mistake to choose a build system
over the other because "I love Xyz, Xyz is the only way. You're all
wrong."

Who knows, maybe the answer to "Which new build system for Qt" could
be neither CMake, neither Qbs.

My 2 cents,
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 logging/tracing session notes

[Christian Gagneraud]

On 12 October 2017 at 10:10, Arnaud Clère
 wrote:
> Regarding the ParTraP language, currently, you need to parse, transform and 
> classify
> unstructured traces in a JSON form to be able to use it. JSON will remain the 
> pivot format
> between trace stores and tools so, if ETW or whatever native format is used 
> to store
> traces, there must be a conversion tool... Stay tuned!

LTT uses the "Common Trace Format":

See http://diamon.org/ctf/

Worth reading as well:
http://www.efficios.com/pub/linuxcon2010/presentation-linuxcon-trace-format-2010.pdf
https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-44a4f27eba32/entry/howto_tracing_with_lttng?lang=en
https://www.slideshare.net/ennael/2013-kernel-recipeslttgtkwave


> I will now try to answer the ones regarding modmed... and digress to explain 
> what IMO we should
>  examine and discuss regarding Qt tracing.
> 1/ Avoid numeric and binary data formatting by offering a serializable binary 
> format.
> 2/ Avoid memory allocations.
> 3/ Limit indirection levels from tracepoint to output.

I think these 3 points come for free with LTT/CTF.

The CTF Trace Stream Description Language (TSDL) could be useful to
modmedLog, traced structures could be defined in TSDL language.
Run-time support code could be generated from this.
Your "bind" mechanism could then be be used to
populate/serialise/queue the traces?
See http://diamon.org/ctf/#spec7

CTF is used for other tooling such as linux perf framework, ftrace,
and certainly more.

Given that CTF is an open standard, there should not be any issues to
convert  them to JSON, thought I'm not sure this is the most efficient
way to deal with massive amount of traces.

> Regarding your concerns about locks, there must be some mechanism to avoid 
> mixing
>  events from multiple threads but native APIs certainly provide very 
> efficient solutions.
> On our side, if we avoid dynamic allocations, we should be able to avoid 99% 
> of the
> locks by writing in a reasonably large buffer before sending the result to 
> native APIs.
> Would that be enough?

My point here is that the Qt logging framework is not appropriate
simply b/c it was not design for high perf tracing.
LTT/CTF have a very high throughput, with minimal impact on the
observed system .
These tools are *at least* an order of magnitude faster than an
instrumenting profiler (source: some slides, sorry I forgot the url).

I've just ran a 20s LTT session (kernel traces only) in which i just
started QtCreator. I ended up with 300+MB of binary traces. I could
not notice any slow down whatsoever during the tracing session. CTF
traces can be arbitrary simple or complex.
Eg. just an example:
event {
name = "syscall_exit_epoll_ctl";
id = 503;
stream_id = 0;
fields := struct {
integer { size = 64; align = 8; signed = 1; encoding =
none; base = 10; } _ret;
};
};

event {
name = "syscall_exit_epoll_wait";
id = 502;
stream_id = 0;
fields := struct {
integer { size = 64; align = 8; signed = 1; encoding =
none; base = 10; } _ret;
integer { size = 32; align = 8; signed = 0; encoding =
none; base = 10; } _fds_length;
integer { size = 8; align = 8; signed = 0; encoding =
none; base = 10; } _overflow;
struct {
struct {
integer { size = 64; align = 8; signed
= 0; encoding = none; base = 16; } _u64;
integer { size = 32; align = 8; signed
= 0; encoding = none; base = 10; } _fd;
}_data_union;
integer { size = 32; align = 8; signed = 0;
encoding = none; base = 16; } _raw_events;
struct {
integer { size = 1; align = 1; signed
= 0; encoding = none; base = 10; } _EPOLLIN;
integer { size = 1; align = 1; signed
= 0; encoding = none; base = 10; } _EPOLLPRI;
integer { size = 1; align = 1; signed
= 0; encoding = none; base = 10; } _EPOLLOUT;
integer { size = 1; align = 1; signed
= 0; encoding = none; base = 10; } _EPOLLERR;
integer { size = 4; align = 1; signed
= 0; encoding = none; base = 10; } _padding;
}_events;
} _fds[ _fds_length ];
};
};

Net_dev traces are way more complicated than the above, see
https://pastebin.com/bAebsWr6

Anyway, enough about LTT/CTF, I'll try to spend some time on the
windows ETW 
(https://msdn.microsoft.com/en-us/library/windows/desktop/bb968803(v=vs.85).aspx)

Chris

PS:
I am unable to clone any repo from your forge. HTTPS times out and SSH
gives me a  permission denied.

OT:
I saw recently ARM Streamline in action, it's quite impressive,
horse-work seems to be implemented in kernel space, but you 

Re: [Development] QtCS 2017 logging/tracing session notes

[Christian Gagneraud]

On 11 October 2017 at 21:20, Christian Gagneraud <chg...@gmail.com> wrote:
> In the kernel mode case, you access the events from /proc, which is
> backed by a kernel RCU list/buffer, i don't know how they have
> implemented their userspace solution, but i'm expecting something
> "pretty well done".

Interesting, on Fedora, installing lttng-ust pulls in a package named
"userspace-rcu"...

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 logging/tracing session notes

[Christian Gagneraud]

Hi,

Going through the wiki, the pdf and the codereview again, i see 3
different things:
- Qt: Logging framework
- ModMed: real-time dissection of organised/structured logs
- Ltt/ETW: event tracing/profiling

Different needs, different means, different reasons and different goals.

I like all 3! ;)

But i'm a bit worry of perf inpact on Ltt/ETW, if one wanted to
integrate them into the "structured" logging framework.
I've never heard of ETW before, so i won't comment. Regarding Ltt, I
would say that their primary design goal is stealthiness, the second
one being efficiency.
In the kernel mode case, you access the events from /proc, which is
backed by a kernel RCU list/buffer, i don't know how they have
implemented their userspace solution, but i'm expecting something
"pretty well done".

My point is that Ltt doesn't interfere (much) with the observed
system, and it's I think a primary quality that cannot be thrown away.
Letting Ltt traces go though the whole qDebug stuff makes me feel
nervous, traces shouldn't go though Qt locks.

Concerning the pending code review, what will happen next? Will this
be merged somewhere?
What if I want to share some experiments about Qt event tracing on top
of this review? (time permitting)
Now that the framework is there, it should be quite easy to pollute Qt
with new traces. I used pollute on purpose, b/c that's really the
drawback with Ltt, you have to pollute your code with macros at key
locations.

On the side: ModMed's ParTraP language looks very interesting, could
this be made accessible to Ltt/ETW?

Chris

On 10 October 2017 at 22:48, Thiago Macieira  wrote:
> == Discussion ==
> * Structured logging:
> ** We want to extract information from logs and detect common messages. For
> example:
> {|
> ! From
> ! To
> |-
> |
> Got message "Hello"
> |
> Got message "%s"   Hello
> |-
> |
> Got message "World"
> |
> Got message "%s"   World
> |}
> ** We want to allow logging to store ancillary data, possibly in machine-
> readable format, likely not part of the message itself
> *** Like journald API can do
> *** How do we allow different formatting depending on backend? Needs to
> support formatting user types too.
> * Structured output
> ** Store to databases, for example
> ** Do we still obey QT_MESSAGE_PATTERN?
> ** Select backend with environment variable
>
> Need to review with [https://codereview.qt-project.org/185287 LTTNG and ETW
> tracing]
>
>  Requirements? 
> performance similar to the current state (or provide choice)
>
> streaming generates a lot of code
>
> do not change qdebug but provide structured tracing as a new facility
>
> == Welcome text ==
>
> Qt-based devices such as Medical Cyber-Physical Systems could be developed,
> verified and validated more efficiently using structured logs. We suggest Qt
> Logging enhancements that would facilitate both human exploration and
> automated analysis with Python or other tools. The session will allow:
> * gathering your feedback
> * examining which enhancements would be useful to Qt
> and how to contribute them...
>
>  Enhancements? 
> extended handler with format
>
> less literals in tracepoints
>
> TSV+JSON vs text-only
>
> Bind
>
> format-free handler
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 logging/tracing session notes

[Christian Gagneraud]

On 10 October 2017 at 22:48, Thiago Macieira  wrote:
> do not change qdebug but provide structured tracing as a new facility

Any chance this can be made lock-free from a caller point of view?
(PS: I don't even know if qDebug streaming is lock-free and i'm
interested to know the answer:))
A lock-free callee site has the advantage of not influencing (much)
multi-threading issues. Observing is disturbing as they say.

I'm very interested in lock-free remote tracing.
On the GammaRay and binutils mailing lists I talked/monologued about
an event tracing plugin for gammaray based on ELF symbol overwriting,
at some point I was suggested to go towards official Qt hooks [1].
Could this "Structured logging" be it?
I have as well investigated LTTng, but didn't like their userspace
boiler plate. In the past, I used LTT in kernel mode and it was very
simple (LTT was originally made for the Linux Kernel).  My (personal)
conclusion is: if in userspace, better implement your own solution.

AFAIU, you have somewhow integrated userspace LTTng with Qt logging
and have a MS Windows equivalent (ETW).
Looking quickly at the code review, I can see that a very few qtbase
source files have been patched, and a new tool has been added.

Could this "Structured logging" provide something along the lines of
event handler and event dispatcher profiling/tracing?

In any cases, this looks promising, big thumb up!
Chris


[1] 
https://mail.kdab.com//pipermail/gammaray-interest/2017-September/000281.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] codereview website down?

[Christian Gagneraud]

https://codereview.qt-project.org is not loading, it hangs. Is it just for me?


Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Is qt.io down?

[Christian Gagneraud]

Hi there,

Is qt.io and all *.qt.io down for you or is it just me?

Krys.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Module for Serial Buses

[Christian Gagneraud]

On 27/05/15 03:04, Thiago Macieira wrote:
 On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote:
 My first suggestion is to give the module a better name. Bus is an
 overloaded term with many meanings and it is IMO too close to our DBus
 module. Why not go with what your first sentence in the email used:

  We’d like to create a new Qt module for serial buses

 Call it the Qt module for accessing serial buses, QtSerialBus :)

 Agreed, but why can't this be an extension of QtSerialPort?

 QtSerialPort is not about just 9-pin connectors and UART, since it does
 support serial over USB too.

Maybe, but at the end of the day, a serial port is just a serial port 
(over USB or not), you still end up with a 9-pin connector on one end 
and a TTY interface on the other end (talking UNIX).

There are as well virtual serial ports and serial ports over network 
too. And I'm not talking about the generic TTY thingy, I'm talking about 
the 9-pin connector devices.

My 2 cents.



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtModeling - the last mile

[Christian Gagneraud]

On 26/05/15 07:18, Sandro Andrade wrote:
 On Wed, Apr 29, 2015 at 6:08 PM, Sandro Andrade sandroandr...@kde.org wrote:
 On Wed, Apr 29, 2015 at 6:01 PM, Konstantin Ritt ritt...@gmail.com wrote:
 Any links/code/docs?)

 Yes, sorry :)

 Wiki page: http://wiki.qt.io/QtModeling
 Git repository: http://www.gitorious.org/qt/qtmodeling
 DuSE-MT (QtModeling-based tool) website: http://duse.sourceforge.net/
 DuSE-MT repository: www.gitorious.org/duse-mt/duse-mt

 Some posts about QtModeling:
 https://liveblue.wordpress.com/2012/12/11/call-for-arms-qtmofqtuml/
 https://liveblue.wordpress.com/2013/01/21/qtmofqtuml-xmi-serialization-and-metamodel-plugins/
 https://liveblue.wordpress.com/2013/11/18/how-cute-can-modeling-be/

 Cheers,
 Sandro

 So, anyone ? Let's put this baby out :)
 I'll present a talk about QtModeling at Akademy this year. If any of
 you guys is also heading there, we might
 schedule a chat.

BTW, the page at http://duse.sourceforge.net/ has quite a few broken 
links pointing to http://qt.gitorious/qtplayground/qtmof.
Shouldn't they point to https://github.com/qtproject/qtmodeling instead?

Krys



 Cheers,
 Sandro



 Konstantin

 2015-04-30 0:26 GMT+04:00 Sandro Andrade sandroandr...@kde.org:

 Hi there,

 Some time ago, I started the development of QtModeling : a qt add-on
 aimed at providing metamodeling features and the basic infrastructure
 for dealing with software models. It already has a lot of interesting
 features and now I have the available time to making it good enough to
 be released.

 There are, however, some design choices I would like to discuss and
 get some feedback from some of you guys. Implementing the UML
 metamodel, for example, requires a considerable time investiment. Part
 of this is already done, but I would like to set up a plan to
 incrementally release such features.

 So, would anyone be willing to provide some guidance and keep up with
 QtModeling to its release ?

 Thanks in advance,
 --
 Sandro
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Introducing Qt Gamepad, a new qt-labs project

[Christian Gagneraud]

On Wed, 13 May 2015 08:00:07 Nichols Andy wrote:
  On 13 May 2015, at 01:04, Christian Gagneraud
  chg...@gna.orgmailto:chg...@gna.org wrote:
  
  Any chance QtGamepad would provide support for devices like the
  SpaceNavigator (3D mouse) [1]? I recently posted a question about this on 
  this mailing list [2].
  These 3D mice send events for translation and rotation around all 3 Axis,
  I  don't know how well they fit with gamepads. Accdording to [3] it seems
  to fit in terms of events, the only exception is that the space navigator
  requires it's own protocol handler [4]
  
  Krys.
  
  [1] http://www.3dconnexion.eu/products/spacemouse/spacenavigator.html
  [2] http://lists.qt-project.org/pipermail/interest/2015-April/016294.html
  [3]http://code.qt.io/cgit/qt-labs/qtgamepad.git/tree/src/plugins/gamepads/
  evdev/qevdevgamepadbackend.cpp
  [4] http://sourceforge.net/p/spacenav/code/HEAD/tree/trunk/libspnav/

 I have a one of those 3dconnexion SpaceNavigator’s as well, but it
 definitely doesn’t make sense in the Qt Gamepad module, as it is
 intentionally limited to just Gamepad devices instead of a generic input
 device framework.  I will say that if you are interested in using the
 SpaceNavigator with Qt there was actually support for using it in the
 original Qt3D (1.0) release and possibly the 4.8 version.  It is not in the
 current Qt3D release (and I don’t think it should be either), but you could
 pull out the removed code in Qt3D 1.0 and possibly make it into its own
 module or library for use in applications where it makes sense.

Yes you ar right, it doesn't really fir in the gamepad category.
I've just found on gitorious the source code you talked about [1], that's the 
only git repository containing the 3D mouse code, Qt3D-1.0 for Qt4 doesn't 
have it, even in the git history.
Thanks for pointing me to this.

Krys
[1] https://qt.gitorious.org/qt-labs/qt3d


 Regards,
 Andy Nichols

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Introducing Qt Gamepad, a new qt-labs project

[Christian Gagneraud]

On Tue, 12 May 2015 16:16:00 Nichols Andy wrote:
 You may have noticed if you religiously watch #qt-labs or just poke around
 on code.qt.io page that a new project has recently been added to qt-labs. 
 QtGamepad is a spare-time / creative Friday project that I've been playing
 with on-and-off since 2012.  Some of you may have seen the first version
 available on my Github account, but the new version available now on
 qt-labs has been mostly rewritten.
 
 http://code.qt.io/cgit/qt-labs/qtgamepad.git/
 
 The now available version is loosely inspired by the HTML 5 Gamepad API:
 http://www.w3.org/TR/2015/WD-gamepad-20150414/
 but now with a much more Qt-like API.  There are both C++ and QtQuick APIs
 available for interacting with Gamepad devices, as well as some convience
 APIs for mapping gamepad buttons to keyboard buttons (to for example drive
 and existing interface with 5-key navigation).
 
 Right now there is a plugin architecture for providing different backends
 for interacting with gamepads.  The current backends include: XInput -
 Windows
 evdev - Linux
 SDL2 - Any platform supported by SDL2 (we just use their Gamepad module)
 
 I'm also currently working on the native OSX/iOS backend (now that I
 actually have an iOS Gamepad to test)
 
 The Qt Gamepad module should already be useful for many of you who would
 like to play with Gamepad interactions in your Qt Applications, but there
 also is some additional work that needs to be done to improve this module
 so feedback and contributions are appreciated as usual ;-)

Hi Andy,

Any chance QtGamepad would provide support for devices like the SpaceNavigator 
(3D mouse) [1]? I recently posted a question about this on this mailing list 
[2].
 These 3D mice send events for translation and rotation around all 3 Axis,  I 
don't know how well they fit with gamepads. Accdording to [3] it seems to fit 
in 
terms of events, the only exception is that the space navigator requires it's 
own protocol handler [4]

Krys.

[1] http://www.3dconnexion.eu/products/spacemouse/spacenavigator.html
[2] http://lists.qt-project.org/pipermail/interest/2015-April/016294.html
[3] 
http://code.qt.io/cgit/qt-labs/qtgamepad.git/tree/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp
[4] http://sourceforge.net/p/spacenav/code/HEAD/tree/trunk/libspnav/


 
 Regards and happy hacking,
 Andy Nichols
 @nezticle
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QGView and deprecated indirect painting

[Christian Gagneraud]

On 08/04/15 00:10, Paul Olav Tvete wrote:
 On Wednesday 1. April 2015 13.28.50 Christian Gagneraud wrote:
 So, my question is: Do you guys plan to remove this feature, and if yes
 (which seems likely to me), how could I then control colors, opacity and
 drawing order on a per view basis?

 There is very little new development for graphics view. Essentially, we focus
 on stability, and only serious bugs are fixed. I will be very surprised if
 anyone would think it is a good idea to do a large change to remove features
 at this point, even if they are deprecated.

 However, there is a theoretical possibility that changes in other parts of Qt
 could break this feature, and in that case we might not prioritize fixing 
 those
 bugs.

 TL;DR: No plans to remove it, but no guarantees that it will always continue
 working.

Hi Paul,

Thanks for the clarification.

Chris


 - Paul
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QGView and deprecated indirect painting

[Christian Gagneraud]

Hi Trolls!

Note: I'm sending this email to qt-dev not to qt-interest because it 
deals with deprecated features and API changes of the Qt Graphics View 
framework.

QGraphicsView has an optimisation flag called IndirectPainting, which 
when set restore the old painting algorithm that calls 
QGraphicsView::drawItems() and QGraphicsScene::drawItems(). and is 
marked as To be used only for compatibility with old code.

I would like to use this feature to achieve per view painting controls 
such as:
- item transparency and colors (effect)
- drawing order

In my context, there is one main view (the working view) and other 
auxiliary views (typically in dock widgets), a picture being worth a 
thousand word, here is an example of the sort of things I'm after: 
http://techdocs.altium.com/display/ADOH/Working+with+the+Board+Insight+System#WorkingwiththeBoardInsightSystem-SingleLayerMode

So, my question is: Do you guys plan to remove this feature, and if yes 
(which seems likely to me), how could I then control colors, opacity and 
drawing order on a per view basis?

I think it is a very good feature to allow the view to take control of 
painting over the QGItems and the QGScene. (on the side, i think as well 
that it is way better to let the view handle mouse and keyboard events 
instead of the scene or the items)

Thanks,
Krys
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Add widgets into qt3d window

[Christian Gagneraud]

On 31/03/15 01:08, Arjun Das wrote:
 Hi ,

 I have created a simple qt3d application in c++, which has a rotating cube.
 I would like to add buttons to the windows to stop/start rotating the
 cube. I am not able to see such an example anywhere in the qt3d examples
 which has support for widgets.

I recently came across this, but can't remember if it was on this list 
or stackoverfow. Anyway, there is a solution that allows you to make the 
Qt3D::Window behave as a widget, I think twiddling with it's 
Qt::WindowFlags is enough, something like view-setFlags(Qt::Widget).

Krys


 Could anyone please help me?

 Thanks

 Regards
 Arjun



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problems running Qt3D examples

[Christian Gagneraud]

Hi Sean,

On 24/03/15 22:33, Sean Harmer wrote:
 Hi,

 On Tuesday 24 March 2015 13:09:23 Christian Gagneraud wrote:
 Hi there,

 I've just build qt5 from git (5.5 branch, commit cdc3bf5) and I'm having
 problems running some qt3d examples.

 I've run *all* examples and only a few don't work:
 - assimp, multiviewport: window content is black

 This will only work if the assimp libs and headers are found by pkgconfig at
 build time. Remove your Qt3d build including the .qmake.cache file, install 
 the
 assimp development package and rebuild Qt3d. If it still fails to detect
 assimp take a look in the generated config.log file for hints.

That was it, thanks! Now only gltf is not working, but i'll discard that 
one as you suggested.

libassimp looks nice, but it seems to be geared towards games and 
animation, that's a pity it doesn't support STEP files [1] which is the 
widely used in the CAD/EDA world. STEP is a more complex beast thought, 
any chance to see a stepcode [2] based SceneParser one day? Should I 
open a feature request on bugreports.qt.io?

[ 5minutes later]

As usual, as i'm writing this email, diging Qt and assimp code, I found 
some references to ISO10303 in libassimp, the code refers to a Industry 
Foundation Classes loader, which opens .ifc files, not sure if it the 
same as step files I'm used to, will keep investigating...

Thanks a lot,
Krys

[1] http://en.wikipedia.org/wiki/ISO_10303
[2] https://github.com/stepcode/stepcode


 - gltf: window content is never drawn

 The gltf spec is still evolving. We should disable this until it matures more.
 Please disregard for now.

 Don't know if it's related, but the following examples gives me a
 warning message 'Xlib: extension NV-GLX missing on display :0' but
 run fine:
 - simple-cpp
 - materials
 - loader-qml
 - deferred-renderer-qml
 - deferred-renderer-cpp
 - cylinder-cpp
 - cpp_example
 - wave
 - wireframe

 Yes I see this too but have not been able to track it down yet but I don't see
 any bad side effects from it.


 These one don't run and give me the NV-GLX warning:
 - gltf
 - assimp

 These ones don't run and don't produce the NV-GLX warning:
 - multiviewport

 This also uses the assimp scene loader so without assimp support you won't see
 anything here.


 Some examples produce as well messages like 'Xlib: sequence lost
 (0x1026b  0x26d) in reply type 0x23!':
 - shadow-map-qml
 - deferred-renderer-qml
 - defered-renderer-cpp

 All other examples run fine with no Xlib warnings.

 I'm running KUbuntu 14.10, with all the updates, my GPU config is:
 GL_VERSION:  4.4.0 NVIDIA 331.113
 GL_VENDOR:   NVIDIA Corporation
 GL_RENDERER: Quadro 600/PCIe/SSE2

 I'm not sure what the problem is, is it a Qt issue, an NVIDIA driver
 issue or maybe i'm missing some libs or using the wrong OpenGL lib?

 Here are some libs debugging info:
 $ LD_DEBUG=libs ./assimp/assimp 21 | grep -i gl | grep -v libglib
26728: find library=libGL.so.1 [0]; searching
26728:   trying
 file=/home/krys/src/qt5/build/qtbase/lib/libGL.so.1
26728:   trying file=/usr/lib/nvidia-331/libGL.so.1
26728: find library=libnvidia-glcore.so.331.113 [0]; searching
26728:   trying
 file=/usr/lib/nvidia-331/libnvidia-glcore.so.331.113
26728: calling init:
 /usr/lib/nvidia-331/libnvidia-glcore.so.331.113
26728: calling init: /usr/lib/nvidia-331/libGL.so.1
26728: find library=libxcb-glx.so.0 [0]; searching
26728:   trying
 file=/home/krys/src/qt5/build/qtbase/lib/libxcb-glx.so.0
26728:   trying file=/usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
26728: calling init: /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
26728: calling init:
 /home/krys/src/qt5/build/qtbase/plugins/xcbglintegrations/libqxcb-glx-integr
 ation.so Xlib:  extension NV-GLX missing on display :0.
26728: calling fini:
 /home/krys/src/qt5/build/qtbase/plugins/xcbglintegrations/libqxcb-glx-integr
 ation.so [0]
26728: calling fini: /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 [0]
 26728: calling fini: /usr/lib/nvidia-331/libGL.so.1 [0]
26728: calling fini:
 /usr/lib/nvidia-331/libnvidia-glcore.so.331.113 [0]

 So it looks to me that i'm using the right freshly built Qt library and
 the right NVidia proprietary drivers.

 All looks as I see too, except for the lack of assimp support.

 Cheers,

 Sean
 --
 Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
 Klarälvdalens Datakonsult AB, a KDAB Group company
 Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
 KDAB - Qt Experts - Platform-independent software solutions
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Problems running Qt3D examples

[Christian Gagneraud]

Hi there,

I've just build qt5 from git (5.5 branch, commit cdc3bf5) and I'm having 
problems running some qt3d examples.

I've run *all* examples and only a few don't work:
- assimp, multiviewport: window content is black
- gltf: window content is never drawn

Don't know if it's related, but the following examples gives me a 
warning message 'Xlib: extension NV-GLX missing on display :0' but 
run fine:
- simple-cpp
- materials
- loader-qml
- deferred-renderer-qml
- deferred-renderer-cpp
- cylinder-cpp
- cpp_example
- wave
- wireframe

These one don't run and give me the NV-GLX warning:
- gltf
- assimp

These ones don't run and don't produce the NV-GLX warning:
- multiviewport

Some examples produce as well messages like 'Xlib: sequence lost 
(0x1026b  0x26d) in reply type 0x23!':
- shadow-map-qml
- deferred-renderer-qml
- defered-renderer-cpp

All other examples run fine with no Xlib warnings.

I'm running KUbuntu 14.10, with all the updates, my GPU config is:
GL_VERSION:  4.4.0 NVIDIA 331.113
GL_VENDOR:   NVIDIA Corporation
GL_RENDERER: Quadro 600/PCIe/SSE2

I'm not sure what the problem is, is it a Qt issue, an NVIDIA driver 
issue or maybe i'm missing some libs or using the wrong OpenGL lib?

Here are some libs debugging info:
$ LD_DEBUG=libs ./assimp/assimp 21 | grep -i gl | grep -v libglib
  26728: find library=libGL.so.1 [0]; searching
  26728:   trying 
file=/home/krys/src/qt5/build/qtbase/lib/libGL.so.1
  26728:   trying file=/usr/lib/nvidia-331/libGL.so.1
  26728: find library=libnvidia-glcore.so.331.113 [0]; searching
  26728:   trying 
file=/usr/lib/nvidia-331/libnvidia-glcore.so.331.113
  26728: calling init: 
/usr/lib/nvidia-331/libnvidia-glcore.so.331.113
  26728: calling init: /usr/lib/nvidia-331/libGL.so.1
  26728: find library=libxcb-glx.so.0 [0]; searching
  26728:   trying 
file=/home/krys/src/qt5/build/qtbase/lib/libxcb-glx.so.0
  26728:   trying file=/usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
  26728: calling init: /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
  26728: calling init: 
/home/krys/src/qt5/build/qtbase/plugins/xcbglintegrations/libqxcb-glx-integration.so
Xlib:  extension NV-GLX missing on display :0.
  26728: calling fini: 
/home/krys/src/qt5/build/qtbase/plugins/xcbglintegrations/libqxcb-glx-integration.so
 
[0]
  26728: calling fini: /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 [0]
  26728: calling fini: /usr/lib/nvidia-331/libGL.so.1 [0]
  26728: calling fini: 
/usr/lib/nvidia-331/libnvidia-glcore.so.331.113 [0]

So it looks to me that i'm using the right freshly built Qt library and 
the right NVidia proprietary drivers.

Any help appreciated,
Krys

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] = 5.3 bug? GraphicsView and mouse event doubleclick flag

[Christian Gagneraud]

Hi Trolls!

The documentation said that the Qt::MouseEventCreatedDoubleClick flag of 
Qt::​MouseEventFlags Indicates that Qt has created a 
MouseButtonDblClick event from this event. The flag is set in the 
causing MouseButtonPress, and not in the resulting MouseButtonDblClick.
It is marked as since Qt 5.3, and the corresponding issue ticket is 
actually
https://bugreports.qt.io/browse/QTBUG-25831

I'm am trying to use this feature (w/ Qt 5.4) for a QGraphicsView 
(placed on a QtDesigner based MainWindow) and i've traced the event 
calls when doing a double click:
- mouse press event w/ empty flags
- mouse release event with empty flags
- mouse double click event with empty flags
- mouse release event with empty flags

So basically my view never receive the event with the 
MouseEventCreatedDoubleClick falg set.

In the description of QTBUG-25831, it seems that only QWidgetWindow 
receive the event with the falg set, but not the QWidget.

Is this a bug, a feature, or am I missing something?

Regards,
Chris

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setup QT creator for developing QT apps on wandboard-Error

[Christian Gagneraud]

On 29/07/2014 4:46 p.m., Nilesh Kokane wrote:
[...]
 Manage:
 Name:wandboard-solo
 Authentication type :password
 Host Name:minda-HP-dx2480-MT-VP562PA
 SSH port:22
 usearname:root
 Password:

 1)With that when i tried to test  the device with the ethernet
 connection i'm getting the following error

 Error:
 Connecting to host...
 SSH connection failure: Connection refused

 Device test failed.

Did you first manually test the connection to your board?
How does the hostname minda-HP-dx2480-MT-VP562PA get resolved?

Can you even ping the board? can you even log remotely to the board?

try these first:
$ ping minda-HP-dx2480-MT-VP562PA

and if it works, try this:
$ ssh root@minda-HP-dx2480-MT-VP562PA

If the above two tests pass, then QtCreator should be able to connect too.

Well, according to the doc you've cited, you need to use the IP address 
of the board, and in order to know its IP address you need to log 
through a serial console, and check it's ip address with the ifconfig 
command (as explained in the doc)

Chris

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setup QT creator for developing QT apps on wandboard-Error

[Christian Gagneraud]

On 29/07/2014 4:46 p.m., Nilesh Kokane wrote:

 Hello ,


 referring to
 http://wiki.wandboard.org/index.php/Setup_QT_creator_for_developing_QT_apps_on_wandboard#Build_and_Deploy_application_in_QT_Creator

[...]

 2)The second error is that even a simple default Qt console app program
 is generating the ld error as follows.But native compiled version gives
 a success.

[...]
 collect2: error: ld returned 1 exit status
 make: *** [untitled6] Error 1
 17:40:35: The process /usr/bin/make exited with code 2.
 Error while building/deploying project untitled6 (kit: i.mx6)
 When executing step 'Make'
 17:40:35: Elapsed time: 00:01.

You might be better off pointing your linker to your sysroot instead of 
the Yocto managed Qt build directory, aren't all your libs inside your 
sysroot? You can check for that with this command:
$ find 
/home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo 
-name libicui18n.so.51 -o -name libz.so.1

What I don't understand in your case, is why the documentation tells you 
that you need meta-qt5 on one hand, and then tells you to manually 
cross-compile Qt5 just to setup QtCreator? According to your logs, you 
seem to use the yocto one anyway.

What does this command gives?
$ sh -x ./qtcreator.sh

Maybe you still have a typo somewhere in your script.

Have you tried the bitbake meta-toolchain-qt5 command?

Chris



 Can you please let me know if some steps are erroneous or missing.

 Thanks
 Nilesh Kokane



 “The contents of this e-mail message and any attachments are
 confidential and are intended solely for addressee. The information may
 also be legally privileged. This transmission is sent in trust, for the
 sole purpose of delivery to the intended recipient. If you have received
 this transmission in error, any use, reproduction or dissemination of
 this transmission is strictly prohibited. If you are not the intended
 recipient, please immediately notify the sender by reply e-mail or phone
 and delete this message and its attachments, if any.”


 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Christian Gagneraud]

On 10/07/2014 11:19 p.m., Mitch Curtis wrote:

 On 07/10/2014 12:20 PM, Ch'Gans wrote:
 On 09/07/14 19:53, Andrea Barna wrote:
 Hi,

 I am Andrea from Digia Qt, I have recently taken over the Qt
 businessin your region.
 Hi Andrea,

 All the best for your new position!

 I noticed that you downloaded the trial version of Qt last year and
 Iwas wondering whether the evaluation went well.

 It would be helpful to understand why you were evaluating Qt, and
 learn more about what type of application you are developing.
 I downloaded your evaluation version of Qt to see how different it is
 from the open source one. I am especially interested in embedded and
 industrial application and as such I was curious about your Boot to Qt
 technology.
 I was not really surprised to discover that your proprietary Boot to
 Qt technology is based on the open-source Yocto project [1], and I
 think that instead of keeping this technology closed, you should be the
 official maintainer of the Qt5 Yocto layer (lot of work is needed there,
 and you have handles in-house), I think you should contact the Linux
 Foundation [2], they will be glad to see you being a major actor in the
 open-source embedded Linux world.

Furthermore is there anything that Digia–Qt can help you with?

 Definitely yes: please open up your open source based
 commercial/proprietary boot to Qt technology.
 I am not asking that because I am an open-source fanatic, I am asking
 that because this is the only reliable and efficient way to get Qt
 massively adopted on the embedded/industrial Linux market, I think that
 Digia should be a (publicly visible) key actor in this sector.

 Maybe one day you will be able to replace your Code once, run
 everywhere with Code once, run everywhere, without pain!.
 Getting Qt5 + Yocto + OpenGL-ES running across different ARM SoCs is a
 real pain.

 Best regards,
 Chris

 PS: No disrespect to you, Digia, Nokia, TrollTech and all the Qt trolls,
 hat off and thumb up to all you guys! I am just tired to see a beautiful
 open-source SW community being permanently fooled by professional
 closed-source HW company. Please don't be part of this masquerade!

 PS2: I've CC'ed the Qt developer mailing list (public archived available
 [3]), hoping this could be useful to someone, somehow, someday.

 [1] https://www.yoctoproject.org/
 [2] http://www.linuxfoundation.org/about/contact
 [3] http://lists.qt-project.org/pipermail/development/


 I'm curious how you think Digia can fund future development of things 
 like Boot to Qt if they give it away for free?

Boot To Qt for Embedded Linux (Not talking about android here), is based 
on Yocto (which is open-source), there exists a Qt5 layer (Dedicated 
Yocto sub-project), and I think that Digia should be the official 
maintainer of this project. Digia could work hand and hand with Silicon 
Company like Intel, Texas Instrument, Freescale, Xilinx (these companies 
maintain their own SoC specific Yocto layers). Everyone would win if the 
Qt5 Layer was in a good shape and tested on platform based on the 
above-mentioned SoC's manufacturers.
Today, these SoC manufacturers provide SDKs (Linux kernel + cross 
toolchain + demo image) and few provide a SDK that contains Qt5. I think 
it is Digia's role to help spread the Qt technology on embedded Linux.

On the side, Qt3 (yes this is not a mistake, it is a three) is 
officially supported by Yocto (courtesy of Intel) for the sake of LSB 
compliance...
http://git.yoctoproject.org/cgit/cgit.cgi/meta-qt3/tree/README

Chris



 I look forward to hearing about your project. 
 Best Regards,
 Andrea

 Andrea Barna | Junior Sales Executive
 Digia Norway AS, Sandakerveien 116, PoBOX 23 Nydalen, 0410 Oslo, Norway
 Email: andrea.ba...@digia.com | Phone : +47 210 80 420 | Fax : +47 
 21080439
 http://qt.digia.com |Qt Blog: http://blog.qt.digia.com/ |Qt 
 Facebook: www.facebook.com/qt  |Qt Twitter: @QtbyDigia

 --
 PRIVACY AND CONFIDENTIALITY NOTICE
 This message and any attachments are intended only for use by the 
 named addressee and may contain privileged and/or confidential 
 information. If you are not the named addressee you should not 
 disseminate, copy or take any action in reliance on it. If you have 
 received this message in error, please contact the sender 
 immediately and delete the message and any attachments accompanying 
 it. Digia Plc does not accept liability for any corruption, 
 interception, amendment, tampering or viruses occurring to this 
 message.
 -



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Christian Gagneraud]

On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
 On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
 Boot To Qt for Embedded Linux (Not talking about android here), is based
 on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
 Yocto sub-project), and I think that Digia should be the official
 maintainer of this project. Digia could work hand and hand with Silicon
 Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
 maintain their own SoC specific Yocto layers). Everyone would win if the
 Qt5 Layer was in a good shape and tested on platform based on the
 above-mentioned SoC's manufacturers.
 Today, these SoC manufacturers provide SDKs (Linux kernel + cross
 toolchain + demo image) and few provide a SDK that contains Qt5. I think
 it is Digia's role to help spread the Qt technology on embedded Linux.

 Participating in Yocto by maintaining the Qt5 layer and working on Boot to Qt
 are orthogonal to each other.

 Digia could do both if it wanted to.

Well at least before they started Boot to Qt w/ Android, working on 
boot to Qt implied polishing the Yocto Qt5 layer or writing another one 
from scratch. They obviously did some work on that and it's a pity that 
nothing have been given back to the community. That was my point.

 Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
 see the problem with that either: the Qt Project has a lot of people from
 different companies collaborating together. We don't depend on Digia doing
 everything.

No, Qt doesn't depend on Digia, but Digia depends on Qt!
When you look at their Qt Enterprise Embedded, it's Qt, QtCreator, 
QtSimulator, GNU, Linux, Android,  with a pinch of Enterprise 
plug-in's and add-on's all well packed together.

 Besides, IIRC the Boot to Qt project was trying to use the Android base layer
 because that's the best BSP that most silicon vendors provide. Notably, the
 vendors not participating in Yocto.

They might have switched to Android (Well, apparently not really [1], 
Yocto is used both for targeting Android and Pure Embedded Linux), but 
AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux 
(using Yocto or similar), whereas it takes 10 times longer with Android.

Having said all these, Digia has its own business model, maybe I was 
expecting Digia to behave much like Nokia, my mistake.

Chris

[1] 
http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS2014 - QtPrintSupport Session

[Christian Gagneraud]

On 14/06/14 05:06, John Layt wrote:
 Hi,

 The notes form the QtPrintSupport session are available at
 https://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtPrintSupport
 .  Basically it's a long list of all the work needing to be done to
 finish the new print library.  While a lot is dependent on me finding
 time, there are tasks other people could take on, primarily greatly
 improving our PDF writer support and adding equivalent XPS file format
 support for Windows.

Hi,

Link support would be very nice to have, not sure if it's on the 
priority list or not, but I'm sure lot of people would like to have 
support for this.

Chris


 For those in attendance, I've done a little more work on Windows XPS
 format support, basically despite what MSDN says full XPS based print
 workflow is available from Vista SP2 onwards, so that's likely to be
 the minimum support level for the new library.  Details at
 http://qt-project.org/wiki/Qt-5-QtPrint#5a06d2a1c54c0764bb13f0440156e4c7.

 Cheers!

 John.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


-- 
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of static ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Windows Online Installer problem(s)

[Christian Gagneraud]

On 07/02/14 20:11, Heikkinen Jani wrote:
 Hash mismatch was because qt5.2.1 content was replicating to the mirrors at 
 that time.

Hi Jani,

There's still some problems with the windows online installer, being in 
New Zealand, I'm redirected to ftp.yz.yamagata-u.ac.jp.
The installer failed to download a package for android 
(foo-bar-baz-dwarf-something.7z).

BTW, do you have plan to sign your package? Right now, there's just a 
checksum file.

Chris



 Br,
 Jani

 -Original Message-
 From: Chris Gagneraud [mailto:chg...@googlemail.com] On Behalf Of
 Christian Gagneraud
 Sent: 6. helmikuuta 2014 22:30
 To: Heikkinen Jani; development@qt-project.org
 Subject: Re: [Development] Windows Online Installer problem(s)

 On 05/02/14 20:12, Heikkinen Jani wrote:
 Hi all,
 When did you tried that online installation?

 I just checked the Windows computer and this was Qt 5.2.0, not 5.2.1.

 Chris


 Br,
 Jani

 -Original Message-
 From: development-bounces+jani.heikkinen=digia@qt-project.org
 [mailto:development-bounces+jani.heikkinen=digia@qt-project.org]
 On Behalf Of Christian Gagneraud
 Sent: 5. helmikuuta 2014 4:03
 To: development@qt-project.org
 Subject: [Development] Windows Online Installer problem(s)

 Hi there,

 I tried to install Qt with the latest official online installer on a
 Windows computer [1], and I couldn't install it on the 'D' disk, because
 the 'C' disk didn't have enough space to store the downloaded data (I
 guess in the system temp dir, which is likely to be on c:)

 Another annoying (but non blocking) problem I had was a hash
 mismatch
 on
 one of the Android component, the work around in my case was simply
 to
 unselect the 2 android components via the settings dialogue.
 I tried to re-run the installer 3 times, and 3 times I had a hash
 mismatch, so the problem seems to be on the server side.

 I ended up installing Qt using the offline installer.

 Chris

 [1]
 http://download.qt-
 project.org/official_releases/online_installers/1.5/qt-
 windows-opensource-1.5.0-x86-online.exe
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Windows Online Installer problem(s)

[Christian Gagneraud]

On 05/02/14 20:12, Heikkinen Jani wrote:
 Hi all,
 When did you tried that online installation?

On the 5th of February (few hours before sending the email).

Chris


 Br,
 Jani

 -Original Message-
 From: development-bounces+jani.heikkinen=digia@qt-project.org
 [mailto:development-bounces+jani.heikkinen=digia@qt-project.org]
 On Behalf Of Christian Gagneraud
 Sent: 5. helmikuuta 2014 4:03
 To: development@qt-project.org
 Subject: [Development] Windows Online Installer problem(s)

 Hi there,

 I tried to install Qt with the latest official online installer on a
 Windows computer [1], and I couldn't install it on the 'D' disk, because
 the 'C' disk didn't have enough space to store the downloaded data (I
 guess in the system temp dir, which is likely to be on c:)

 Another annoying (but non blocking) problem I had was a hash mismatch
 on
 one of the Android component, the work around in my case was simply to
 unselect the 2 android components via the settings dialogue.
 I tried to re-run the installer 3 times, and 3 times I had a hash
 mismatch, so the problem seems to be on the server side.

 I ended up installing Qt using the offline installer.

 Chris

 [1]
 http://download.qt-project.org/official_releases/online_installers/1.5/qt-
 windows-opensource-1.5.0-x86-online.exe
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Windows Online Installer problem(s)

[Christian Gagneraud]

On 05/02/14 20:12, Heikkinen Jani wrote:
 Hi all,
 When did you tried that online installation?

I just checked the Windows computer and this was Qt 5.2.0, not 5.2.1.

Chris


 Br,
 Jani

 -Original Message-
 From: development-bounces+jani.heikkinen=digia@qt-project.org
 [mailto:development-bounces+jani.heikkinen=digia@qt-project.org]
 On Behalf Of Christian Gagneraud
 Sent: 5. helmikuuta 2014 4:03
 To: development@qt-project.org
 Subject: [Development] Windows Online Installer problem(s)

 Hi there,

 I tried to install Qt with the latest official online installer on a
 Windows computer [1], and I couldn't install it on the 'D' disk, because
 the 'C' disk didn't have enough space to store the downloaded data (I
 guess in the system temp dir, which is likely to be on c:)

 Another annoying (but non blocking) problem I had was a hash mismatch
 on
 one of the Android component, the work around in my case was simply to
 unselect the 2 android components via the settings dialogue.
 I tried to re-run the installer 3 times, and 3 times I had a hash
 mismatch, so the problem seems to be on the server side.

 I ended up installing Qt using the offline installer.

 Chris

 [1]
 http://download.qt-project.org/official_releases/online_installers/1.5/qt-
 windows-opensource-1.5.0-x86-online.exe
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Windows Online Installer problem(s)

[Christian Gagneraud]

Hi there,

I tried to install Qt with the latest official online installer on a 
Windows computer [1], and I couldn't install it on the 'D' disk, because 
the 'C' disk didn't have enough space to store the downloaded data (I 
guess in the system temp dir, which is likely to be on c:)

Another annoying (but non blocking) problem I had was a hash mismatch on 
one of the Android component, the work around in my case was simply to 
unselect the 2 android components via the settings dialogue.
I tried to re-run the installer 3 times, and 3 times I had a hash 
mismatch, so the problem seems to be on the server side.

I ended up installing Qt using the offline installer.

Chris

[1] 
http://download.qt-project.org/official_releases/online_installers/1.5/qt-windows-opensource-1.5.0-x86-online.exe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] GLSL Optimizer

[Christian Gagneraud]

On 02/03/2014 10:17 PM, Sean Harmer wrote:
 Hi,

 On Sunday 02 February 2014 17:09:24 Michal Lazo wrote:
 Hi
 I found pretty nice article about shaders optimization in arm GPU drivers

 For example Unity3d use it in there shaders compiler
 http://aras-p.info/blog/2010/09/29/glsl-optimizer/

 https://github.com/aras-p/glsl-optimizer
 https://github.com/stskeeps/glsl-optimizer


 As it is really easy to add it to Qt OpenGL module.
 Many people simple don't write really optimised shaders and this can help.

 Looks interesting. If you'd like to submit a patch please add me as reviewer.
 In any case this should be an optional step as we've had a few cases where
 some embedded drivers mis-compile/mis-optimise GLSL shaders and so we would
 not want to have this enabled for all systems I think.

HAM radio enthusiasts are after as well!:
http://www.cruisersforum.com/forums/f134/weatherfax-97533-3.html

And this was the (windows) tip of the iceberg:
https://sdr.osmocom.org/trac/wiki/fosphor

GLSL Optimizer is important.

Chris


 Cheers,

 Sean

 --
 Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
 Klarälvdalens Datakonsult AB, a KDAB Group company
 Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
 KDAB - Qt Experts - Platform-independent software solutions
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLog updated for 5.2.0

[Christian Gagneraud]

On 19/11/13 17:02, Thiago Macieira wrote:
 I've just updated the Changelog for 5.2.0 with the output from the script that
 I've just uploaded at https://codereview.qt-project.org/71641. The changelog

The help message still refer to header-diff BTW.

my 2 cents,
Chris

 update is at https://codereview.qt-project.org/71642.

 There were exactly 31 commits with [ChangeLog]. Please start using it more.

 Here's the raw output before I manually merged and fixed mistakes:

 $ perl qtsdk/packaging-tools/create_changelog.pl . v5.1.0..origin/release

 Important Behavior Changes
 --

   - The supported date range in QDateTime has been reduced to about +/- 292
 million years, the range supported by the number of msecs since the Unix
 epoch of 1 Jan 1970 as stored in a qint64, and as able to be used in the
 setMSecsSinceEpoch() and toMSecsSinceEpoch() methods.

   - QUrl and QUrlQuery:
 * [QTBUG-31660] QUrl no longer considers all delimiter characters
   equivalent to their percent-encoded forms. Now, both classes always
   keep all delimiters exactly as they were in the original URL text.
 * QUrl no longer supports QUrl::FullyDecoded mode in authority() and
   userInfo(), nor QUrl::DecodedMode in setAuthority() and setUserInfo().
 * [QTBUG-31945] QUrl no longer decodes %23 found in the fragment to #
   in the output of toString(QUrl::FullyEncoded) or toEncoded()
 * QUrl now defaults to decoded mode in the getters and setters for
   userName, password, host, topLevelDomain, path and fileName. This
   means a '%' in one of those fields is now returned (or set) as '%'
   rather than %25. In the unlikely case where the former behavior was
   expected, pass PrettyDecoded to the getter and TolerantMode to the
   setter.
 * QUrl now normalizes the path given in setPath, removing ./ and ../ and
   duplicate slashes.

 QtCore
 --

   - QDateTime:
 * [QTBUG-26161][QTBUG-29666] Fully implement support for Qt::TimeSpec of
   Qt::OffsetFromUTC, added new methods for offsetFromUTC(),
   toTimeSpec(), and toOffsetFromUTC().
 * Added convenience methods for fromMSecsSinceEpoch() and fromTime_t()
   to take time spec to be used in returned datetime.
 * Add method timeZoneAbbreviation() to return effective time zone
   abbreviation.
 * The debug datastream is now an ISO-like format instead of Qt::TextDate
 * The Standard Time to Daylight Time transition for Qt::LocalTime is now
   handled correctly. Any date set in the missing hour is now
   considered invalid. All date math results that fall into the missing
   hour will be automatically adjusted to a valid time in the following
   hour.
 * Added new method isDaylightTime() to return if the datetime is in
   Daylight Time or not.
 * Add support for a new Qt::TimeZone spec to be used with QTimeZone to
   define times in a specific time zone.

   - QJsonValue:
 * Added QJsonValue::toInt().

   - QStandardPaths:
 * QStandardPaths::enableTestMode is deprecated and is replaced by
   QStandardPaths::setTestModeEnabled.

   - QTime:
 * Added new methods fromMSecsSinceStartOfDay() to create a new QTime
   from an msecs value, and msecsSinceStartOfDay() to return the QTime as
   the number of msecs since the start of the day.

   - QTimeZone:
 * Added new QTimeZone class to support time tone calculations using the
   host platform time zone database and the Olsen time zone ID's.

   - QUtf8:
 * [QTBUG-33229] UTF-8 now accepts non-character unicode points; these
   are not replaced by the replacement character anymore

   - QVariant:
 * Fixed QVariant::canConvert with longlong
 * Variant containing enum types can now be converted to integer

 QtDeclarative
 -

   - ColorDialog:
 * Added currentColor property.

 QtGui
 -

   - QPolygonF:
 * When a QVariant holds a QPolygonF() then it will be correctly seen as
   a null QVariant.

 QtPrintSupport
 --

   - QPrintDialog:
 * Added support for setting CUPS job options in the print dialog.
 * Added support for setting CUPS Banner pages in the print dialog.
 * Added support for setting CUPS Page Set (even/odd pages only) in the
   print dialog.
 * Added support for setting CUPS Pages Per Sheet and Pages Per Sheet
   Layout options
 * Added CUPS server-side print range support for apps that can't support
   print range option themselves

 QtWidgets
 -

   - QAbstractItemView:
 * [QTBUG-7232] QTBUG-7232 - In ItemViews scrollbars will now by default
   only scroll 1 pixel when scrollMode is set to scrollPerPixel. That is
   it will (when scrollMode is scrollPerPixel) do what is stated in the
   documentation, and no longer automatically adjust the scrollbars
   singleStep. The user can now control that value.

   - QHeaderView:
 * 

[Development] Qt-5.1, qglobal.h and PIC detection

[Christian Gagneraud]

Hi,

I'm using CLang build-analize tool, and when I switched from Qt 4.8 to 
Qt 5.1 (insalled from Qt project's download area), I got a Qt #error, 
basically the code is built with -fPIC, but CLang doesn't define a PIC 
macro, so the build fails due to a check in qglobal.h (see details below).

Is it possible to use CLang 3.2 with Qt 5.1 on Linux, or do I need to 
use amore recent verion of CLang or maybe wait for Qt 5.2?

Any hint appreciated,
Chris

# Clang version on Ubunutu 13.04:
$  clang --version
Ubuntu clang version 3.2-1~exp9ubuntu1 (tags/RELEASE_32/final) (based on 
LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix

# No PIC macros defined by CLang:
$ clang -dM -E -x c /dev/null |grep -i 'PIC\|PIE\|ELF'
#define __ELF__ 1

The build log:

[...]
/usr/share/clang/scan-build/c++-analyzer -c -pipe -O2 -Wall -W 
-D_REENTRANT -fPIC -DUTILS_LIBRARY -DQT_NO_DEBUG -DQT_XML_LIB 
-DQT_CORE_LIB -I/opt/lambda/2013.10/5.1.1/gcc/mkspecs/linux-g++ -I. 
-I/opt/lambda/2013.10/5.1.1/gcc/include 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtXml 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtCore -I. -o fileutils.o 
fileutils.cpp
In file included from qtcassert.cpp:30:
In file included from ./qtcassert.h:33:
In file included from ./utils_global.h:4:
/opt/lambda/2013.10/5.1.1/gcc/include/QtCore/qglobal.h:975:4: error: 
You must build your code with position independent code if Qt was built 
with -reduce-relocations.  Compile your code with -fPIC or -fPIE.
#  error You must build your code with position independent code if Qt 
was built with -reduce-relocations. \
^
1 error generated.
[...]


And in qglobal.h:975

#if !defined(QT_BOOTSTRAPPED)  defined(QT_REDUCE_RELOCATIONS)  
defined(__ELF__)  !defined(__PIC__)  !defined(__PIE__)
#  error You must build your code with position independent code if Qt 
was built with -reduce-relocations. \
  Compile your code with -fPIC or -fPIE.
#endif

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt-5.1, qglobal.h and PIC detection

[Christian Gagneraud]

On 06/11/13 12:25, Olivier Goffart wrote:
 On Wednesday 06 November 2013 12:17:56 Christian Gagneraud wrote:
 Hi,

 I'm using CLang build-analize tool, and when I switched from Qt 4.8 to
 Qt 5.1 (insalled from Qt project's download area), I got a Qt #error,
 basically the code is built with -fPIC, but CLang doesn't define a PIC
 macro, so the build fails due to a check in qglobal.h (see details below).

 Is it possible to use CLang 3.2 with Qt 5.1 on Linux, or do I need to
 use amore recent verion of CLang or maybe wait for Qt 5.2?

 Simply add -fPIC or -fPIE.

 clang -fPIE -dM -E -x c /dev/null |grep -i 'PIC\|PIE\|ELF'

 #define __ELF__ 1
 #define __PIC__ 2
 #define __PIE__ 2
 #define __pic__ 2
 #define __pie__ 2


Good point, it works here as well, but I still have the error when 
building my code, scan-build replace the calls to g++ by clang++ (using 
CXX=clamg++), but the -fPIC get lost somewhere...
To get it working, I have to do:
$ scan-build 'make CC=${CC} CXX=${CXX}'

So maybe, i'm not using it correctly

While debugging, here is the output of scan-build:


$ scan-build -v -v -v 'make CC=${CC} CXX=${CXX}'
scan-build: Using '/usr/bin/clang' for static analysis
scan-build: Emitting reports for this run to '/tmp/scan-build-2013-11-06-7'.
/usr/share/clang/scan-build/c++-analyzer -c -pipe -O2 -Wall -W 
-D_REENTRANT -fPIC -DUTILS_LIBRARY -DQT_NO_DEBUG -DQT_XML_LIB 
-DQT_CORE_LIB -I/opt/lambda/2013.10/5.1.1/gcc/mkspecs/linux-g++ -I. 
-I/opt/lambda/2013.10/5.1.1/gcc/include 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtXml 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtCore -I. -o fileutils.o 
fileutils.cpp
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DUTILS_LIBRARY 
-DQT_NO_DEBUG -DQT_XML_LIB -DQT_CORE_LIB 
-I/opt/lambda/2013.10/5.1.1/gcc/mkspecs/linux-g++ -I. 
-I/opt/lambda/2013.10/5.1.1/gcc/include 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtXml 
-I/opt/lambda/2013.10/5.1.1/gcc/include/QtCore -I. -o fileutils.o 
fileutils.cpp

[LOCATION]: /home/christiaga/projects/lambda-simulator/utils
#SHELL (cd '/home/christiaga/projects/lambda-simulator/utils'  
'/usr/bin/clang++' '-cc1' '-triple' 'i386-pc-linux-gnu' '-analyze' 
'-disable-free' '-disable-llvm-verifier' '-main-file-name' 
'fileutils.cpp' '-analyzer-store=region' 
'-analyzer-opt-analyze-nested-blocks' '-analyzer-eagerly-assume' 
'-analyzer-checker=core' '-analyzer-checker=unix' 
'-analyzer-checker=deadcode' 
'-analyzer-checker=security.insecureAPI.UncheckedReturn' 
'-analyzer-checker=security.insecureAPI.getpw' 
'-analyzer-checker=security.insecureAPI.gets' 
'-analyzer-checker=security.insecureAPI.mktemp' 
'-analyzer-checker=security.insecureAPI.mkstemp' 
'-analyzer-checker=security.insecureAPI.vfork' '-analyzer-output' 
'plist' '-w' '-mrelocation-model' 'static' '-mdisable-fp-elim' 
'-fmath-errno' '-masm-verbose' '-mconstructor-aliases' 
'-fuse-init-array' '-target-cpu' 'pentium4' '-target-linker-version' 
'2.23.2' '-momit-leaf-frame-pointer' '-resource-dir' 
'/usr/bin/../lib/clang/3.2' '-D' '_REENTRANT' '-D' 'UTILS_LIBRARY' '-D' 
'QT_NO_DEBUG' '-D' 'QT_XML_LIB' '-D' 'QT_CORE_LIB' '-I' 
'/opt/lambda/2013.10/5.1.1/gcc/mkspecs/linux-g++' '-I' '.' '-I' 
'/opt/lambda/2013.10/5.1.1/gcc/include' '-I' 
'/opt/lambda/2013.10/5.1.1/gcc/include/QtXml' '-I' 
'/opt/lambda/2013.10/5.1.1/gcc/include/QtCore' '-I' '.' 
'-fmodule-cache-path' '/var/tmp/clang-module-cache' '-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7' 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7/i686-linux-gnu'
 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7/backward' 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/i386-linux-gnu/c++/4.7'
 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/i386-linux-gnu/c++/4.7/i686-linux-gnu'
 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/i386-linux-gnu/c++/4.7/backward'
 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++' 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/i686-linux-gnu' 
'-internal-isystem' 
'/usr/bin/../lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/backward' 
'-internal-isystem' 
'/usr/local/include' '-internal-isystem' 
'/usr/bin/../lib/clang/3.2/include' '-internal-isystem' 
'/usr/include/clang/3.2/include/' '-internal-externc-isystem' 
'/usr/include/i386-linux-gnu' '-internal-externc-isystem' 
'/usr/include/i686-linux-gnu' '-internal-externc-isystem' '/usr/include' 
'-fdeprecated-macro' '-fdebug-compilation-dir' 
'/home/christiaga/projects/lambda-simulator/utils' '-ferror-limit' '19' 
'-fmessage-length' '0' '-mstackrealign' '-fobjc-runtime=gcc' 
'-fcxx-exceptions' '-fexceptions' '-fdiagnostics-show-option' 
'-analyzer-display-progress' '-analyzer-output=html' '-o' 
'/tmp/scan-build-2013-11-06-7' '-x' 'c++' 'fileutils.cpp')
In file included from