Re: [Development] Qt 6 buildsystem support requirements

[Thiago Macieira]

On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> Hi,
> 
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
> 
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.

Now that is nice, as we know that the moc, uic, rcc outputs are platform-
independent. That should help reduce the build times on Windows for debug-and-
release builds, as running moc is a significant portion of the build time.

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

Re: [Development] Qt 6 buildsystem support requirements

[Thiago Macieira]

On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote:
> On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
> 
>  wrote:
> > Hello
> > 
> > Having spent far too much time trying to figure out why crappy
> > buildsystems
> > cause failures in distros (like TensorFlow or libvpx - see
> > https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to
> > make sure this doesn't happen to Qt 6. For that, I'd like to add the
> > following extra requirements to the buildsystem we choose to use. This is
> > in addition to the functionality requirements.
> > 
> > These apply to the buildsystem at the time of Qt's the switch to it.
> 
> Will the switch coincide with 6.0 ? If yes, does it have to or could
> the switch happen at Qt > 6.0.0 whenever we have a *good* solution ?

The plan was to switch for 6.0. It could happen later if we don't get 
consensus and is too disruptive earlier, though. But 6.0 is the perfect time, 
as we drop old platforms and can reliably require people to upgrade to new 
things.

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

Re: [Development] gsl::owner (Was: Setters: Clarifying the ownership)

[André Pönitz]

On Tue, Jul 31, 2018 at 02:51:41PM +0200, Giuseppe D'Angelo via Development 
wrote:
> Hi,
> 
> On 31/07/18 13:11, Sérgio Martins via Development wrote:
> > I would recommend however that our docs show T* instead of gsl::owner
> > and continue to include "Takes ownership of foo" in the text.
> > While I believe in self-documenting signatures I think it's too much
> > noise and hurts readability, and most devs never heard of gsl.
> > 
> > Should be just an aid for tooling IMO.
> 
> I agree with the rest of your email, but I kind of disagree with this
> particular point, for different reasons:
> 
> 
> * Because we need to educate our users that there's more C++ than Qt out
> there, and the Core Guidelines and the GSL are a fundamental part of
> knowledge for a C++ developer.

Pluralis Majestatis?

"Educating [o]ur users" etc are not exactly unworthy goals, but when it
comes to using that as reason *against* traditional Qt principles like
"consistent API", "ease of use" I don't think this "[w]e" covers everybody
here. Certainly not "Us".

> [...]
> * Leaving gsl::owner in the signature of a function documentation can help
> clarify situations where the textual documentation does not say anything
> about the ownership.

And that can and should be solved be adding the corresponding stanza to
the docs, not by doc uglification. In case they were really missing, and
this is not just speculation.

> However, from a practical point of view, unless someone adds gsl::owner
> _everywhere_ to Qt, we can't report it in the docs, as they would otherwise
> be inconsistent :-(

"We" appreciate that You consider inconsistency a problem. 1/2 ;-)

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

Re: [Development] Qt 6 buildsystem support requirements

[Sérgio Martins]

On Wed, Aug 1, 2018 at 8:46 PM, BogDan Vatra via Development
 wrote:
> Hi,
>
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
>
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.

And probably do a single moc and uic pass if you want ? The rules
system is pretty flexible.

Regards,
Sergio Martins



>
> On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira
>  wrote:
>>
>> On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development
>> wrote:
>>>
>>>  Hi,
>>>
>>>Did you knew that qbs can build all but windows targets at once from
>>> your
>>>  Linux machine?
>>
>>
>> That's not news. qmake can do that, provided you have the toolchains. You
>> could compile for Mac and MSVC too, if you had them (for MSVC, via Wine,
>> like
>> godbolt.org).
>>
>>>  Using mingw you can cross compile Qt for windows, but you
>>>  probably want to run tests and to check if the code compiles with msvc.
>>>  This feature might not seem pretty useful for linux, but is very useful
>>> for
>>>  Android where we can bundle multiple platforms in the same package.
>>
>>
>> Agreed.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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 6 buildsystem support requirements

[Sérgio Martins]

On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
 wrote:
> Hello
>
> Having spent far too much time trying to figure out why crappy buildsystems
> cause failures in distros (like TensorFlow or libvpx - see
> https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make
> sure this doesn't happen to Qt 6. For that, I'd like to add the following
> extra requirements to the buildsystem we choose to use. This is in addition to
> the functionality requirements.
>
> These apply to the buildsystem at the time of Qt's the switch to it.

Will the switch coincide with 6.0 ? If yes, does it have to or could
the switch happen at Qt > 6.0.0 whenever we have a *good* solution ?


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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,

qmake can't compile them all *at once* e.g. $ qmake && make will compile only 
one target at the time not all.

AFAIK QBS and iirc gn too, are the only few that have this cool feature.

Cheers,
BogDan.

On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development
>wrote:
>> Hi,
>> 
>>   Did you knew that qbs can build all but windows targets at once
>from your
>> Linux machine? 
>
>That's not news. qmake can do that, provided you have the toolchains.
>You 
>could compile for Mac and MSVC too, if you had them (for MSVC, via
>Wine, like 
>godbolt.org).
>
>> Using mingw you can cross compile Qt for windows, but you
>> probably want to run tests and to check if the code compiles with
>msvc.
>> This feature might not seem pretty useful for linux, but is very
>useful for
>> Android where we can bundle multiple platforms in the same package.
>
>Agreed.
>
>-- 
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Thiago Macieira]

On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development wrote:
> Hi,
> 
>   Did you knew that qbs can build all but windows targets at once from your
> Linux machine? 

That's not news. qmake can do that, provided you have the toolchains. You 
could compile for Mac and MSVC too, if you had them (for MSVC, via Wine, like 
godbolt.org).

> Using mingw you can cross compile Qt for windows, but you
> probably want to run tests and to check if the code compiles with msvc.
> This feature might not seem pretty useful for linux, but is very useful for
> Android where we can bundle multiple platforms in the same package.

Agreed.

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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,

  Did you knew that qbs can build all but windows targets at once from your 
Linux machine? Using mingw you can cross compile Qt for windows, but you 
probably want to run tests and to check if the code compiles with msvc.
  This feature might not seem pretty useful for linux, but is very useful for 
Android where we can bundle multiple platforms in the same package.


Cheers,
BogDan.

On August 1, 2018 7:37:13 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote:
>> This is easy to do in any build system that supports out-of-source
>> (a.k.a. "shadow") builds - notably including the existing qmake-based
>> builds for Qt.  I never want to do an in-source build of anything.
>
>And not just that. Building out-of-source is an absolute requirement.
>
>With one set of Qt sources, I build:
> - debug
> - release
> - clang release
> - icc release
> - i386 release namespace
> - MSVC 2017 (source dir is mounted read-only in the VM)
>
>Plus discontinued (used to build, haven't in over 2 years):
> - ARM 32-bit
> - MIPS 32-bit
> - static
>
>Ditto on the Windows machine, where the same set up, I build:
> - MSVC 2017 64-bit
> - MSVC 2015 64-bit
> - MSVC 2013 64-bit (will stop)
> - ICC 18 MSVC 2017 64-bit (configure only)
> - ICC 18 MSVC 2015 64-bit (only qtbase)
>
>And on the Mac, the same sources builds both frameworks and
>no-frameworks, 
>though I think I haven't built the latter in several years (unlike the
>Mac and 
>Windows laptops, the Mac machine is from 2012, so it has old stuff).
>
>-- 
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Symbol clashes with static Qt libraries

[Thiago Macieira]

On Tuesday, 31 July 2018 07:52:37 PDT Thiago Macieira wrote:
> Well, it could be much worse.  There are a couple of low-hanging fruits
> there that we can easily fix. I'll take a look later today on those
> applying to QtCore.

Done almost all for qtbase, from Kai's listing:

https://codereview.qt-project.org/235707
https://codereview.qt-project.org/235708
https://codereview.qt-project.org/235709
https://codereview.qt-project.org/235710
https://codereview.qt-project.org/235711

The only one I couldn't easily fix were the SHA{224,256,384,512} symbols from 
qcryptographichash.cpp. It's doable but I might have to suppress some 
warnings.

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

Re: [Development] Symbol clashes with static Qt libraries

[Thiago Macieira]

On Wednesday, 1 August 2018 06:48:40 PDT Tor Arne Vestbø wrote:
> > On 1 Aug 2018, at 15:45, Kai Koehne  wrote:
> > 
> > Alright, so it seems we have to prefix the symbols we can't hide by static
> > or anonymous namespaces ...
 
> > For logging categories, I'd like to start using 'qlc' as prefix. See also
> > change https://codereview.qt-project.org/#/c/235631/ for qtbase.
> 
> Namespaces doesn’t work for that?

Namespaces do. Unnamed namespaces don't (used across multiple files).

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

Re: [Development] Qt 6 buildsystem support requirements

[Thiago Macieira]

On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote:
> This is easy to do in any build system that supports out-of-source
> (a.k.a. "shadow") builds - notably including the existing qmake-based
> builds for Qt.  I never want to do an in-source build of anything.

And not just that. Building out-of-source is an absolute requirement.

With one set of Qt sources, I build:
 - debug
 - release
 - clang release
 - icc release
 - i386 release namespace
 - MSVC 2017 (source dir is mounted read-only in the VM)

Plus discontinued (used to build, haven't in over 2 years):
 - ARM 32-bit
 - MIPS 32-bit
 - static

Ditto on the Windows machine, where the same set up, I build:
 - MSVC 2017 64-bit
 - MSVC 2015 64-bit
 - MSVC 2013 64-bit (will stop)
 - ICC 18 MSVC 2017 64-bit (configure only)
 - ICC 18 MSVC 2015 64-bit (only qtbase)

And on the Mac, the same sources builds both frameworks and no-frameworks, 
though I think I haven't built the latter in several years (unlike the Mac and 
Windows laptops, the Mac machine is from 2012, so it has old stuff).

-- 
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] QAbstractItemModel::setItemData behaviour

[Luca Beldi]

Hi everyone,
While trying to submit a patch to fix QStringListModel::setItemData 
https://codereview.qt-project.org/235730 we opened a much larger discussion on 
QAbstractItemModel, that expanded on the forum 
https://forum.qt.io/topic/93207/qabstractitemmodel-setitemdata-partial-success  
but that I ultimately would like your opinion on:

At the moment, QAbstractItemModel::setItemData calls setData for each role 
until the first failure and returns false if that happens.
This opens up 2 issues:

* QAbstractItemModel::setItemData returns false even when some but not 
all data was actually set without rolling back the changes

* QAbstractItemModel::setItemData depends on the ordering of the roles

For the second point, an example that illustrates the problem is 
(QStringListModel::setItemData just uses the base class implementation):
QStringListModel::setItemData({{Qt::DisplayRole,QVariant("test")},{ 
Qt::DecorationRole,QVariant(QIcon())}) will return false but actually set the 
string to "test"
QStringListModel::setItemData({{Qt::EditRole,QVariant("test")},{ 
Qt::DecorationRole,QVariant(QIcon())}) will return false and do nothing on the 
model

My proposal is:

* Remove the ordering-dependency  QAbstractItemModel::setItemData (i.e. 
sets all the roles it can and returns false if any of them failed)

* Make setItemData in subclasses of QAbstractItemModel behave 
transaction-like (i.e. try to set all the roles, if any fails rollback the 
other changes and return false)

This however is technically a change of behaviour so I would like people way 
smarter than me to agree on the way forward.

Thanks,
Regards,
Luca Beldi (aka VRonin)

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

Re: [Development] Qt 6 buildsystem support requirements

[Ville Voutilainen]

On 1 August 2018 at 11:24, Jason Newton  wrote:
>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
>> *a build tool* go, that's pretty insane. Especially if you're not
>> planning to use it to build Java code.
>
> As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular
> openjdk , prospectively in a development environment where you've got
> devel headers and packages installed.   The cost of the dependency is
> neither bloat nor unbounded, it really is just that size on a machine
> that's prepared to build software in 2018.  Please explain what issue
> this presents.

The prospect of having to install a JRE to build Qt or eventually Qt
applications
solicits a fairly loud "I think I'll pass" from me. I don't use java
for anything. Having
it around for a supposedly simple and easy-to-adopt build system is a cost
that I am not eager to pay. Do we expect to package a JRE with Qt? Do we
expect a JRE to be a package dependency of Qt for distro vendors?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Matthew Woehlke]

On 2018-08-01 04:24, Jason Newton wrote:
> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
>> On 2018-07-21 19:52, Jason Newton wrote:
>>> I wanted to mention that this is on my mind alot for a few years days
>>> as a user for a plethora of libraries.  My conclusion for the build
>>> system with the brightest future is bazel [...]
>>
>> No. Just, *no*.
>>
>> Persistent build server? Java? No, thanks.
> 
> This is an option, you can keep it in a preference file, or you can
> use it as a command line switch to not use this.

...and how many naïve users that "just want to build Qt" are going to
know about that?

> As for java in the loop - this is a a build system, how much does it
> matter with what it is written in if the implementation is good?

...because Java is an *enormous* added dependency for something that
*ought* to be light-weight.

>> Maybe it's gotten better, but last I knew, bazel had no notion of
>> "installing" software, which is just a non-starter. It's also heavily
>> optimized for Google's internal usage, and (partly as a result)
>> basically does not play at all nicely with software that's intended to
>> exist in an open source, package-managed ecosystem.
> 
> The convention is that projects using it embrace that and don't care
> about the most system packages if they can get away with it.
Which is *exactly backwards* from what an open source package should be
doing (but typical of *proprietary* software). In fact, it's the very
antithesis of (L)GPL.

Bazel encourages practices that are *bad* for software that wants to
play nicely in an open source ecosystem.

>> On a related note, "hermetic builds" is pretty ironic. Your *build*
>> might be hermetic, but bazel itself is *far* from... it's very reliant
>> on putting all its garbage in "magic locations" in your home directory,
>> unlike most build tools that only need to write to your build directory.
>> Again, *not* friendly for anyone that needs to build Qt as an external
>> dependency.
> 
> Actually that's just a default location - the output location you're
> talking about is the outputRoot/output_base setting:
> https://docs.bazel.build/versions/master/output_directories.html

Again, stuff that users that want it to Just Work aren't going to know
about. And/or that consumers of Qt are going to have to (know to) muck
with. With other build systems, this isn't an issue *in the first place*.

>>> -Ability to build external libraries from source
>>
>> Yeah... no. Building third party libraries yourself is *evil*. And a
>> great way to piss off package maintainers. No open source project should
>> *EVER* rely on, or preferably even use by default, this ability.
> 
> It is not evil in any way.

Every disto, ever, disagrees.

> Bazel doesn't deal with system packages in a first class way.
Right. And this is a big problem for an open source package.

> -Analysis tools for the dependencies, like graphviz, but also memory
> usage and timing info.  A legitimate profiler, have a look:
> https://docs.bazel.build/versions/master/skylark/performance.html
> https://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/
> (admittedly few online examples of this output and this is looks
> different now IIRC)
> -Does a good job of controlling verbosity while keeping the user
> informed on the running targets being processed concurrently while
> giving a quick way to hop out, go serial or show commands executed
> -Workable, like cmake workable, visual studio generator, and xcode outputs.
> -clion has a plugin good direct plugin for it, though more will follow
> and they tried to make it easy for IDEs to incorporate (
> https://blog.bazel.build/2016/06/10/ide-support.html we can agree it'd
> be create if more build systems did this, right?
> https://docs.bazel.build/versions/master/ide.html for fuller list )

Pretty much all of which you *also* have with CMake/ninja...

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

Re: [Development] Symbol clashes with static Qt libraries

[Tor Arne Vestbø]

> On 1 Aug 2018, at 15:45, Kai Koehne  wrote:
> 
> Alright, so it seems we have to prefix the symbols we can't hide by static or 
> anonymous namespaces ...
> 
> For logging categories, I'd like to start using 'qlc' as prefix. See also 
> change https://codereview.qt-project.org/#/c/235631/ for qtbase.

Namespaces doesn’t work for that?

> Ossi pointed out in the review that, because it is a private symbol, the 
> 'qt_' prefix would be more correct. Anyhow, that just gets too long ... So 
> I'm asking whether anybody objects making an exception for logging categories.

Agreed, qt_ gets unwieldy, qlc is fine. (Assuming we can’t use a namespace 
instead)

Tor Arne 

> 
> Regards
> 
> Kai
> 
>> -Original Message-
>> From: Development 
>> On Behalf Of Thiago Macieira
>> Sent: Tuesday, July 31, 2018 4:58 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] Symbol clashes with static Qt libraries
>> 
>> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
>>> I favor (a) along with the existing test, because of the issues
>>> Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for 
>>> us.
>> 
>> We will not be able to get (c) working everywhere. I remember trying objcopy
>> some years ago messing with symbol properties and I know I wasn't successful.
>> I don't remember what I was trying, though, so this is not a showstopper for
>> our current problem. Just don't get your hopes up.
>> 
>> I think we need (a) and we can apply (c) if possible.
>> 
>>> If we wanted to make this test work again (and produce errors with
>>> your logging category examples), then we would need a configuration in
>>> the CI that builds on Linux without ELF visibility. At least that's
>>> one of the ways it could be done with minimal effort.
>> 
>> Why can't the test run on .a files?
>> 
>>> It however does not protect us from the issue on Windows and macOS,
>>> but it covers the cross-platform code.
>> 
>> nm exists on both too. We won't get it on MSVC, though.
>> 
>> --
>> 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

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

Re: [Development] Symbol clashes with static Qt libraries

[Kai Koehne]

Alright, so it seems we have to prefix the symbols we can't hide by static or 
anonymous namespaces ...

For logging categories, I'd like to start using 'qlc' as prefix. See also 
change https://codereview.qt-project.org/#/c/235631/ for qtbase.

Ossi pointed out in the review that, because it is a private symbol, the 'qt_' 
prefix would be more correct. Anyhow, that just gets too long ... So I'm asking 
whether anybody objects making an exception for logging categories.

Regards

Kai

> -Original Message-
> From: Development 
> On Behalf Of Thiago Macieira
> Sent: Tuesday, July 31, 2018 4:58 PM
> To: development@qt-project.org
> Subject: Re: [Development] Symbol clashes with static Qt libraries
> 
> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
> > I favor (a) along with the existing test, because of the issues
> > Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for 
> > us.
> 
> We will not be able to get (c) working everywhere. I remember trying objcopy
> some years ago messing with symbol properties and I know I wasn't successful.
> I don't remember what I was trying, though, so this is not a showstopper for
> our current problem. Just don't get your hopes up.
> 
> I think we need (a) and we can apply (c) if possible.
> 
> > If we wanted to make this test work again (and produce errors with
> > your logging category examples), then we would need a configuration in
> > the CI that builds on Linux without ELF visibility. At least that's
> > one of the ways it could be done with minimal effort.
> 
> Why can't the test run on .a files?
> 
> > It however does not protect us from the issue on Windows and macOS,
> > but it covers the cross-platform code.
> 
> nm exists on both too. We won't get it on MSVC, though.
> 
> --
> 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] Qt 6 buildsystem support requirements

[Edward Welbourne]

Singling out just one tiny corner of all that for a passing remark:

Jason Newton (1 August 2018 10:24)
> One of the things I like about the way bazel keeps this is I can jump
> back and forth between an optimized build and a full debug build (for
> example) - they don't erase eachother

This is easy to do in any build system that supports out-of-source
(a.k.a. "shadow") builds - notably including the existing qmake-based
builds for Qt.  I never want to do an in-source build of anything.

> and you can only achieve that jumping capability, being cheap, if you
> add a file-level layer of indirection.

Not sure what you're claiming here, or what system you're claiming lacks
it.  If you've got both optimised and debug builds, you're going to have
both sets of files *somewhere* (whether jumbled up in one directory or
kept separate in two out-of-source build trees).

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

Re: [Development] Qt 6 buildsystem support requirements

[Jason Newton]

On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke
 wrote:
>
> On 2018-07-21 19:52, Jason Newton wrote:
> > I wanted to mention that this is on my mind alot for a few years days
> > as a user for a plethora of libraries.  My conclusion for the build
> > system with the brightest future is bazel [...]
>
> No. Just, *no*.
>
> Persistent build server? Java? No, thanks.

This is an option, you can keep it in a preference file, or you can
use it as a command line switch to not use this .   stat time
performance when monitoring many files, between invocations,
especially if globbing is involved and if you don't have a process
watching with inotify you will need to O(N) check every file for
modification and to hope your platform/hardware makes that check cheap
(windows doesn't,
https://github.com/mesonbuild/meson/blob/master/docs/markdown/FAQ.md#but-i-really-want-to-use-wildcards)
  Better to have a plan to deal with the case than not.  As for java
in the loop - this is a a build system, how much does it matter with
what it is written in if the implementation is good? I am not saying 0
but you should keep this number in check.  Make is made out of
something far more terrible than java.  Cmake is built on c++ but is
difficult to modify and the language they made is a mess.  Java works
in many situations and provides a write-once run anywhere mode that
works most of the time without issue and is performant enough for most
everyday tasks (better than python, and not always a long shot off
from all kinds of c/c++ depending on the application and exact
algorithms ), and importantly it works in this one without any notable
complaints.  OpenJDK has wide coverage for host-build environments:
http://openjdk.java.net - and is packaged by all major distributions,
first class.

>
> Maybe it's gotten better, but last I knew, bazel had no notion of
> "installing" software, which is just a non-starter. It's also heavily
> optimized for Google's internal usage, and (partly as a result)
> basically does not play at all nicely with software that's intended to
> exist in an open source, package-managed ecosystem.

It works well with open source actually, git is a first class data
source, mainly targeting external repositories, frequently github.
Source archive files are too.  The convention is that projects using
it embrace that and don't care about the most system packages if they
can get away with it.  Streamline switching out pkg_config based
results and package-kit or other kinds of datasources and really this
just works.  Discussing this problem upstream will probably get better
capabilities in the box well before expected shift time but your beef
is with closing the gap on package-managed dependencies outside of
bazel, and I'm all for closing it, although even now it is workable.


> (I'd be interested to know if there is *any* software packaged by any
> FLOSS distribution that uses bazel...)
>
> Basically, ask your distributors before even *considering* bazel. My
> suspicion is they're going to tell you that they refuse to package
> anything using it.
>
> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
> *a build tool* go, that's pretty insane. Especially if you're not
> planning to use it to build Java code.

As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular
openjdk , prospectively in a development environment where you've got
devel headers and packages installed.   The cost of the dependency is
neither bloat nor unbounded, it really is just that size on a machine
that's prepared to build software in 2018.  Please explain what issue
this presents.

>
> By comparison, CMake+ninja depend on... a C++ compiler. (Which is also
> needed for Qt itself, of course, so...) I haven't really looked, but I'd
> guess qmake is also pretty light-weight in the dependency department.
>
> > Why the qt project may be interested in this in short is:
> > -Fast and scaling bazel uses a long lived server technique that hangs
> > around
>
> Yeah... that's *just* the sort of thing we should be forcing on users...
> It's even *more* of an anti-feature if some other build systems needs to
> build Qt. (Yes, that happens.)
>
> On a related note, "hermetic builds" is pretty ironic. Your *build*
> might be hermetic, but bazel itself is *far* from... it's very reliant
> on putting all its garbage in "magic locations" in your home directory,
> unlike most build tools that only need to write to your build directory.
> Again, *not* friendly for anyone that needs to build Qt as an external
> dependency.

Actually that's just a default location - the output location you're
talking about is the outputRoot/output_base setting:
https://docs.bazel.build/versions/master/output_directories.html
Again, like gitignore or clang-format, a project can specify it's own
settings and the point of contention is default values with
persecution on capability. I think there's open path ways for change
behaviors that should be changed if 

Re: [Development] Requesting Repository For Python Extension Support in QtCreator

[Lars Knoll]

Sounds good to me.

Cheers,
Lars

On 27 Jul 2018, at 14:37, Tilman Röder 
mailto:tilman.ro...@qt.io>> wrote:

Hello there,

My name is Tilman and I am a software engineering intern at the Qt office in 
Berlin. I'm working on combining PySide2, Shiboken and QtCreator to enable 
Python based extensions in the later. I think that this project has now matured 
enough to be put under proper version control and to show the world a first 
proof of concept. That being said, pretty much everything in the project is 
still subject to change and there will probably be quite a few bugs that have 
not been discovered yet.

Description:

Support Python Extensions by creating bindings for the Core module and Utils 
library of QtCreator (using Shiboken) and by providing a new C++ plugin that 
uses these bindings to execute Python scripts that can interact with QtCreator.

This is an early proof of concept and currently includes the following:
- Some parts of the Core module included as bindings
- MacroExpander from utils as binding (note: due to not unsupported function 
pointers, there are still problems with registering new macros from Python)
- A somewhat isolated embedded CPython runtime for the Python extensions
- Setup mechanism that allows extensions to install dependencies etc.
- Included extension manager written in Python
- Build scripts that should work on most Linux systems, provided the required 
dependencies are installed correctly
(for more details, see the existing GitHub repository)

Responsible: Tilman Roeder

Repository: qt-creator/plugin-pythonextensions

Existing code: https://github.com/dyedgreen/qt-creator-python-extensions
___
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