Re: [Development] Qt 6 buildsystem support requirements

[Jason Newton]

On Thu, Aug 2, 2018 at 11:21 PM Dominik Holland
 wrote:
>
> Am 01.08.18 um 16:40 schrieb 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?
> That would also have a big inpact on the yocto packages, as that would
> require building java itself to compile Qt (yocto usually doesn't use
> prepackaged binaries...),
> and also compile it again for the SDK architecture...
>
> For me JRE as a Qt build dependency is a no-go
>

Have a look at this:
http://zlika.github.io/presentations/compile-openjdk8/slides_en.html#/_generation_of_compact_profiles

If the java packager of the distribution puts in some time with the
openjdk packages they support, they can get it down to 13-25 MiB,
before compression, and 50% of those numbers with.  Bazel doesn't need
gui stuff.

>From OpenSUSE build service, here is the build time for the full
OpenJDK 8 build
https://build.opensuse.org/public/build/Java:Factory/openSUSE_Leap_15.0/x86_64/java-1_8_0-openjdk/_log
- 1976 seconds with what appears to be a single threaded build.  It
should be possible to considerably lean this down.

For control, here is qt5's build file
https://build.opensuse.org/public/build/KDE:Qt:5.11/openSUSE_Leap_15.0/x86_64/libqt5-qtbase/_log
clocking in 2455s

-Jason
___
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]

În ziua de joi, 2 august 2018, la 18:06:02 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote:
> > > 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.
> > > 
> >   It will be nice if this feature is mandatory for Qt 6, so let's add it
> >   to
> > 
> > your requirements list.
> 
> No, this is "nice to have", not mandatory. A reduction in build time would
> be very welcome, but if we don't have it, the build still works.
> 
> >   BTW, not only moc, uic & rcc are platform-independent, but also the
> > 
> > headers (except a few that are generated by configure script which can be
> > moved to platform libs dir). What will be cool really is to unify headers,
> > examples & demos for the Qt SDKs, this way we'll save a lot of space.
> 
> Sorry, I didn't get it. Can you clarify?

Sorry it's kinda off-topic. What I wanted to say is for Qt 6 to have a new SDK 
folders layout. Now each Qt target goes into a separate folder, but the bin, 
include (except a few files), doc, mkspecs, etc. folders are the same. The 
only platform-dependent folders are lib, plugins and qml.
So, instead of:

~/Qt
/5.11.1
  /android_armv7
/bin
/include
/lib
  /gcc_64
/bin
/include
/lib

we'll have:

~/Qt
/6.0.0
  /bin
  /include
  /lib
 /android_armv7 <-- here goes android armv7 libs
/include <-- here goes only android specific headers
/gcc_64 <-- here goes linux amd64 libs
   /include <-- here goes only  linux 64 specific headers

Platform specific headers are those that are generated by configure script.
Of curse the build system must handle this new layout.

Cheers,
BogDan.

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

Re: [Development] Symbol clashes with static Qt libraries

[Olivier Goffart]

On 2018-08-03 08:03, Martin Koller wrote:

On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:

Hi,


Before concluding that a namespaced Qt is a terrible idea, I recommend trying 
out the feature.


It is intended to work transparently and not require any changes to the 
application, nothing like having to type MyNS::QString everywhere.


It may be problematic with forward declarations of Qt types, but the fix for 
that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between 
NS and non-NS builds and does not violate the write once goal.


The correct way to use Qt classes forward declared with (and also without) a 
namespaced Qt build is e.g.:
QT_FORWARD_DECLARE_CLASS(QTimer)

The problem we had with a namespaced Qt were: using external Qt based 
libraries, which never tried to use
a namespaced build, did not build due to forward declarations, so I had to 
patch some of them.
But then, not all external library projects liked these patches so we'd have to 
patch them on our own
increasing the workload when upgrading ...
Also, when using squish you can no longer use a prebuilt version and have to 
compile squish from sources
including also the namespace AFAIR.

Eventually we could go back to non-namespaced builds, which makes your life 
simpler.


Ideally, we should deprecate forward declarations of Qt classes.
We should have a forwarding header, generated by syncqt, which would fordward 
declare all classes on a module.  So one would do #include  to 
forward declare all classes in QtCore.


--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Dominik Holland]

Am 01.08.18 um 16:40 schrieb 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?
That would also have a big inpact on the yocto packages, as that would
require building java itself to compile Qt (yocto usually doesn't use
prepackaged binaries...),
and also compile it again for the SDK architecture...

For me JRE as a Qt build dependency is a no-go

Dominik

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

Re: [Development] JS Engine: callAsConstructor vs. virtualCallAsConstructor

[Lars Knoll]

Hi Valery,

On 2 Aug 2018, at 15:44, Valery Kotov 
mailto:kotov.val...@gmail.com>> wrote:

Hello all,

I have a question about recent introduction of "virtual" functions in 
JavaScript engine.

Now objects have both virtualCallAsConstructor function and callAsConstructor 
functions.
Unfortunately, distinction between those is a little bit unclear to me. Is 
virtualCallAsConstructor is actually what is called when object is created on 
JS side (via new call)? Shall virtuallCallAsConstructor now be used when an JS 
Object is needed to be created from C++ side?

As you know, we have some hand rolled vtables for QV4::Object and friends. The 
declarations of those can now be found in qv4vtable_p.h.

Before, the ‘virtual’ and non regular methods where simply called the same, but 
had different signatures. That gave some conflicts, so I know renamed the ones 
that will be used by the vtable to have a ‘virtual’ prefix.

So if you add your own re-implementation of callAsConstructor you’ll have to 
name it ‘virtualCallAsConstructor’. Like that it’ll end up in the vtable.

If you call a constructor from C++, you can simply do 
functionObject->callAsConstructor() and it’ll forward it to the correct vtable 
method. If you ‘reimplement’ one of those methods (ie. implement a 
virtualCallAsConstructor) and need to call the base implementation, you’ll need 
to call the specific BaseClass::virtualCallAsConstructor method.


I'm also a little bit puzzled about signature:
static ReturnedValue virtualCallAsConstructor(const FunctionObject *f, const 
Value *argv, int argc, const Value *);

What is the last const Value*? Shall I pass args as last the last arguments?

The last value is the newTarget (see 
https://www.ecma-international.org/ecma-262/8.0/#sec-construct). It’s required 
for class constructors. In most cases it’ll be the same as the function object 
that is the constructor.

Cheers,
Lars

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

Re: [Development] Symbol clashes with static Qt libraries

[Martin Koller]

On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:
> Hi,
> 
> 
> Before concluding that a namespaced Qt is a terrible idea, I recommend trying 
> out the feature.
> 
> 
> It is intended to work transparently and not require any changes to the 
> application, nothing like having to type MyNS::QString everywhere.
> 
> 
> It may be problematic with forward declarations of Qt types, but the fix for 
> that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between 
> NS and non-NS builds and does not violate the write once goal.

The correct way to use Qt classes forward declared with (and also without) a 
namespaced Qt build is e.g.:
QT_FORWARD_DECLARE_CLASS(QTimer)

The problem we had with a namespaced Qt were: using external Qt based 
libraries, which never tried to use
a namespaced build, did not build due to forward declarations, so I had to 
patch some of them.
But then, not all external library projects liked these patches so we'd have to 
patch them on our own
increasing the workload when upgrading ...
Also, when using squish you can no longer use a prebuilt version and have to 
compile squish from sources
including also the namespace AFAIR.

Eventually we could go back to non-namespaced builds, which makes your life 
simpler.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


___
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 Thursday, 2 August 2018 10:36:11 PDT Konstantin Tokarev wrote:
> Do you have any prominent examples?

No, sorry. We don't need to cross-compile at the company I work for :-)

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

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de agosto de 2018 14:36:11 -03 Konstantin Tokarev escribió:
> 02.08.2018, 19:50, "Thiago Macieira" :
> > On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
> >>  Unfortunately, Debian does not use cross-compilation for building
> >> packages
> > 
> > Which is unfortunately the case for most (if not all) Linux distributions
> > as a significant number of frameworks and applications don't cross
> > compile at all. So they need to compile on target.
> 
> Do you have any prominent examples? I'm working on embedded software for 8
> years, me and my colleagues have dealt with various open source packages,
> we've never needed to resort to compilation on target or qemu environment.

Out of the box Qt. You need to specifically build it to cross compile stuff, 
which is not what distros look for. What distros need is being able to use the 
real-arch binaries to build the target ones.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
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 Thu, Aug 2, 2018 at 9:34 AM Matthew Woehlke  wrote:
>
> On 2018-08-02 09:03, Oswald Buddenhagen wrote:
> > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
> >> On 2018-08-01 04:24, Jason Newton wrote:
> >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
>  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?
> >>
> > and why exactly would a user who doesn't care ... care?
>
> ...because building Qt just spawned a process that is never going to
> terminate, is going to sit around pointlessly monitoring their file
> system, and is going to potentially cause who-knows-what issues?
>
> If I want to just download and build some package (i.e. I'm not
> *actively developing* that software), doing so shouldn't "infect" my
> machine with zombie processes. When the build is done, it should be *done*.

This is arguing over defaults and for a hypothetical case.  The daemon
exits automatically after a preference-set threshold of time of idle.
 It was engineered and tested for many years to not have problems as
to what you are describing, such as updates to the bazel installation
itself, but it is possible something goes wrong .  The capability
makes sense to everyday developers so the it earns it's place in the
world.  There's a flag to opt out and projects can set defaults that
bazel will respect.  Users can also disable it permanently in their
home preference files and invoke bazel with the switch to disable.  If
that is not sufficient, upstream may listen to behavioral changes such
as opt-out by default and opt-in with flags.


>
> > it's not that i *like* big dependencies, but there is a trade-off to be
> > made, and bazel is *by far* the most advanced build tool on the market
> > today when it comes to optimizing rebuilds of massive projects
>
> ...which is *totally irrelevant* to everyone that is not a Qt developer.
> Just like software is written once and read many times, it is developed
> by a few and deployed by many. Optimizing for development *at the
> expense* of deployment strikes me as... questionable. If the penalty to
> deployment cost was minimal, that would be one thing, but with bazel, it
> isn't.

Perhaps there are strategies to make it reduced by stripping out
things in packages and not depending on a full JRE.  Without swing,
some people have reported getting JRE's down to 10 MiB.  I'll remind
again it depends on a JRE, not a JDK - there's some semblance to
arguing about python usage, in that case.

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

Re: [Development] Qt 6 buildsystem support requirements

[Konstantin Tokarev]

02.08.2018, 19:50, "Thiago Macieira" :
> On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
>>  Unfortunately, Debian does not use cross-compilation for building packages
>
> Which is unfortunately the case for most (if not all) Linux distributions as a
> significant number of frameworks and applications don't cross compile at all.
> So they need to compile on target.

Do you have any prominent examples? I'm working on embedded software for 8 
years,
me and my colleagues have dealt with various open source packages, we've never 
needed
to resort to compilation on target or qemu environment.

There are cross-compiled embedded distros like Buildroot which include 
thousands of
packages.

>
> Sometimes it's an option to use an emulated environment (qemu), but often
> that's even slower than on target. A hybrid approach that runs under qemu and
> runs a native cross compiler disguised as a target compiler is also possible,
> but not easy to achieve.
>
> --
> 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

-- 
Regards,
Konstantin

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

Re: [Development] Qt 6 buildsystem support requirements

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de agosto de 2018 10:57:42 -03 Christian Kandeler escribió:
[snip] 
> > But would be problematic when building for other archs not that powerful
> > as
> > "the normal ones".
> 
> You mean *on* other archs? Because the (cross-)compiler does not care how
> powerful the target architecture is.

Yes, exactly.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Repository request: HTTP server

[Edward Welbourne]

On 10/06/2017 07:10 AM, Fredrik de Vibe wrote:
>> We have recently been working on a research project looking into the 
>> possibilities for creating a lightweight server component that can easily 
>> enable Qt applications to serve over HTTP. We would like to make this work 
>> public and therefore request a repository.
>>
>> This work is intended to continue as a research project, to explore 
>> alternatives and reveal areas that need work, so it should be under qt-labs.
>>
>> Name of the project: Qt HTTP Server
>> Responsible person: Fredrik de Vibe
>> Gerrit user/email: fredrik.dev...@qt.io
>> Desired repository name: qthttpserver

Adam Treat (2 August 2018 17:02)
> What came of this?

Good question.
It's currently on qt-labs, see
https://codereview.qt-project.org/#/q/project:qt-labs/qthttpserver,n,z
for recent reviews.

Eddy.
___
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 Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote:
> Unfortunately, Debian does not use cross-compilation for building packages

Which is unfortunately the case for most (if not all) Linux distributions as a 
significant number of frameworks and applications don't cross compile at all. 
So they need to compile on target.

Sometimes it's an option to use an emulated environment (qemu), but often 
that's even slower than on target. A hybrid approach that runs under qemu and 
runs a native cross compiler disguised as a target compiler is also possible, 
but not easy to achieve.

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

[Matthew Woehlke]

On 2018-08-02 09:03, Oswald Buddenhagen wrote:
> On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
>> On 2018-08-01 04:24, Jason Newton wrote:
>>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
 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?
>>
> and why exactly would a user who doesn't care ... care?

...because building Qt just spawned a process that is never going to
terminate, is going to sit around pointlessly monitoring their file
system, and is going to potentially cause who-knows-what issues?

If I want to just download and build some package (i.e. I'm not
*actively developing* that software), doing so shouldn't "infect" my
machine with zombie processes. When the build is done, it should be *done*.

> it's not that i *like* big dependencies, but there is a trade-off to be
> made, and bazel is *by far* the most advanced build tool on the market
> today when it comes to optimizing rebuilds of massive projects

...which is *totally irrelevant* to everyone that is not a Qt developer.
Just like software is written once and read many times, it is developed
by a few and deployed by many. Optimizing for development *at the
expense* of deployment strikes me as... questionable. If the penalty to
deployment cost was minimal, that would be one thing, but with bazel, it
isn't.

-- 
Matthew
___
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 23:40:40 PDT Lars Knoll wrote:
> > Right, moc files are not cross-platform but I think rcc & uic files are.
> 
> They are still build artefacts, and trying to add logic to figure out which
> of those can be shared between different targets and which can’t sounds
> like a nice way to introduce complexity that will bite us at some point.

Right, and rcc is definitely not a significant portion of the build. We have 
usually at most one rcc run per module. UIC ones are also often limited in 
count, as are the other tools.

moc is the only one that in my mind is "significant portion of the build" and 
Simon is right that we can't share its output.

-- 
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 23:18:51 PDT Simon Hausmann wrote:
> Given that the output of the moc changes depending on what platform and
> compiler dependent pre-processor macros are supplied, I would say that the
> output is not cross-platform.

True, even in debug-and-relaese they could change, as QT_NO_DEBUG changes. 
Someone could #ifdef on it and add properties, signals or slots based on it.

-- 
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 23:13:13 PDT BogDan Vatra via Development wrote:
> > 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.
> 
>   It will be nice if this feature is mandatory for Qt 6, so let's add it to
> your requirements list.

No, this is "nice to have", not mandatory. A reduction in build time would be 
very welcome, but if we don't have it, the build still works.

>   BTW, not only moc, uic & rcc are platform-independent, but also the
> headers (except a few that are generated by configure script which can be
> moved to platform libs dir). What will be cool really is to unify headers,
> examples & demos for the Qt SDKs, this way we'll save a lot of space.

Sorry, I didn't get it. Can you clarify?

-- 
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] Repository request: HTTP server

[Adam Treat]

What came of this?

On 10/06/2017 07:10 AM, Fredrik de Vibe wrote:

Hi all,

We have recently been working on a research project looking into the 
possibilities for creating a lightweight server component that can easily 
enable Qt applications to serve over HTTP. We would like to make this work 
public and therefore request a repository.

This work is intended to continue as a research project, to explore 
alternatives and reveal areas that need work, so it should be under qt-labs.


Name of the project: Qt HTTP Server
Responsible person: Fredrik de Vibe
Gerrit user/email: fredrik.dev...@qt.io
Desired repository name: qthttpserver




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

Re: [Development] Qt 6 buildsystem support requirements

[Konstantin Tokarev]

02.08.2018, 16:58, "Christian Kandeler" :
> On Thu, 2 Aug 2018 10:23:12 -0300
> Lisandro Damián Nicanor Pérez Meyer  wrote:
>
>>  El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
>>  [snip]
>>  > > > 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
>>  >
>>  > the actual toolchain and external dependencies play in the same league.
>>  > ... which is still dwarfed by the size of a single qt debug build.
>>
>>  But would be problematic when building for other archs not that powerful as
>>  "the normal ones".
>
> You mean *on* other archs? Because the (cross-)compiler does not care how 
> powerful the target architecture is.

Unfortunately, Debian does not use cross-compilation for building packages

(Here should be a photo of cluster of low-power SH4 boards which I've seen 
somewhere)

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

-- 
Regards,
Konstantin


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

Re: [Development] Qt 6 buildsystem support requirements

[Christian Kandeler]

On Thu, 2 Aug 2018 10:23:12 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
> [snip] 
> > > > 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  
> > 
> > the actual toolchain and external dependencies play in the same league.
> > ... which is still dwarfed by the size of a single qt debug build.  
> 
> But would be problematic when building for other archs not that powerful as 
> "the normal ones".

You mean *on* other archs? Because the (cross-)compiler does not care how 
powerful the target architecture is.


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

Re: [Development] Symbol clashes with static Qt libraries

[Simon Hausmann]

Hi,


Before concluding that a namespaced Qt is a terrible idea, I recommend trying 
out the feature.


It is intended to work transparently and not require any changes to the 
application, nothing like having to type MyNS::QString everywhere.


It may be problematic with forward declarations of Qt types, but the fix for 
that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between 
NS and non-NS builds and does not violate the write once goal.



Simon


From: Development  on 
behalf of Mathias Hasselmann 
Sent: Thursday, August 2, 2018 3:41:45 PM
To: development@qt-project.org
Subject: Re: [Development] Symbol clashes with static Qt libraries



Am 31.07.2018 um 14:58 schrieb Edward Welbourne:
> Giuseppe D'Angelo (31 July 2018 14:38)
>> It will likely break every single application that has never used a
>> namespaced build of Qt. Which is a significant percentage of all the Qt
>> apps out there...
>
> I'm guessing you mean "... used a static build of Qt." since they're the
> only ones (b) would change, if made the default.  Otherwise, please
> explain how namespaced builds get broken by this - if they were static
> before, then this just makes them the default, so no change; if they
> weren't static, this change won't affect them.
>
> I can believe static-built apps are common;

You are talking about any single Qt application that's built for iOS.
Even worse: Making statically linked Qt use a namespace by default, but
dynamically linked not would seriously break Qt's "write once, build and
run everywhere" promise as there suddenly would be significant
differences between Qt for iOS and Qt for any other platform.

To me enabling namespaces by default seems like a terrible idea.
A total no-go.

Ciao,
Mathias
___
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] JS Engine: callAsConstructor vs. virtualCallAsConstructor

[Valery Kotov]

Hello all,

I have a question about recent introduction of "virtual" functions in
JavaScript engine.

Now objects have both virtualCallAsConstructor function and
callAsConstructor functions.
Unfortunately, distinction between those is a little bit unclear to me. Is
virtualCallAsConstructor is actually what is called when object is created
on JS side (via new call)? Shall virtuallCallAsConstructor now be used when
an JS Object is needed to be created from C++ side?

I'm also a little bit puzzled about signature:
static ReturnedValue virtualCallAsConstructor(const FunctionObject *f,
const Value *argv, int argc, const Value *);

What is the last const Value*? Shall I pass args as last the last arguments?

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

Re: [Development] Symbol clashes with static Qt libraries

[Mathias Hasselmann]

Am 31.07.2018 um 14:58 schrieb Edward Welbourne:

Giuseppe D'Angelo (31 July 2018 14:38)

It will likely break every single application that has never used a
namespaced build of Qt. Which is a significant percentage of all the Qt
apps out there...


I'm guessing you mean "... used a static build of Qt." since they're the
only ones (b) would change, if made the default.  Otherwise, please
explain how namespaced builds get broken by this - if they were static
before, then this just makes them the default, so no change; if they
weren't static, this change won't affect them.

I can believe static-built apps are common;


You are talking about any single Qt application that's built for iOS.
Even worse: Making statically linked Qt use a namespace by default, but 
dynamically linked not would seriously break Qt's "write once, build and 
run everywhere" promise as there suddenly would be significant 
differences between Qt for iOS and Qt for any other platform.


To me enabling namespaces by default seems like a terrible idea.
A total no-go.

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

Re: [Development] Qt 6 buildsystem support requirements

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de agosto de 2018 10:23:12 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
> [snip]
> 
> > > > 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
> > 
> > the actual toolchain and external dependencies play in the same league.
> > ... which is still dwarfed by the size of a single qt debug build.
> 
> But would be problematic when building for other archs not that powerful as
> "the normal ones".
> 
> > > for something that *ought* to be light-weight.
> > 
> > says *who*?
> 
> Good point here. But if I may: largely preferred by distro maintainers.
> 
> Also I don't see bazel packaged in Debian, is it in other distros?

Looking at:



It will take time to get bazel in Debian. And then it will need to fulfill 
Thiago's 2.c points. But it still has two years to accomplish it, as qbs does.


-- 
14: Para acceder y navegar en internet
* Debe tener conexion a Internet
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió:
[snip] 
> > > 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
> 
> the actual toolchain and external dependencies play in the same league.
> ... which is still dwarfed by the size of a single qt debug build.

But would be problematic when building for other archs not that powerful as 
"the normal ones".

> > for something that *ought* to be light-weight.
> 
> says *who*?

Good point here. But if I may: largely preferred by distro maintainers.

Also I don't see bazel packaged in Debian, is it in other distros?

-- 
 1: Una computadora sirve:
* Para tratar de dominar el mundo, un caso conocido de esto fue el de
  Skinet
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Oswald Buddenhagen]

On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
> 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?
> 
and why exactly would a user who doesn't care ... care?

> > 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
>
the actual toolchain and external dependencies play in the same league.
... which is still dwarfed by the size of a single qt debug build.

> for something that *ought* to be light-weight.
> 
says *who*?

it's not that i *like* big dependencies, but there is a trade-off to be
made, and bazel is *by far* the most advanced build tool on the market
today when it comes to optimizing rebuilds of massive projects (esp.
when you have a homogeneous IT environment in your intranet). that might
not be the decisive factor when it comes to choosing a build tool for
qt, but blanket statements like yours don't exactly sound like rational
decision making.

if the spectre of bazel scares you, make your contribution to make sure
qbs makes the cut. ;)
https://www.qt.io/open-positions/software-engineer-build-systems for
that matter ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Oswald Buddenhagen]

On Wed, Aug 01, 2018 at 09:01:40AM +, Edward Welbourne wrote:
> 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.
> 
indeed, that's why the example was badly chosen.

> > 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).
> 
but having fully separate trees for only mildly different builds is
wasteful. a smart developer addresses that by having ccache in the
background, but the solution is more efficient and comprehensive when
the build tool itself implements it.
hence https://bugreports.qt.io/browse/QBS-57
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Joerg Bornemann]

On 08/02/2018 10:05 AM, BogDan Vatra via Development wrote:


Well, if we want to have first class Qt on Android support, this feature
is a

  must. Now, if we can use it also for other platforms that's a

bonus.


Which feature exactly? Creating binaries for multiple targets in on compile
run? Or also only calling rcc once?
  

The first one I can see, the second one would be just an optimisation when
creating multiple binaries.
  
First one.


We're now talking about three different things.


1. Build multiple configurations in one go

E.g. I want to build my project on Linux for Linux x86_64 and 
cross-compile at the same time with MinGW. The project knows nothing 
about this.


This is supported by qbs. [1]


2. Build for multiple platforms in one go

E.g. I want to cross-compile Qt with MinGW  on Linux. Host tools (moc, 
rcc, qlalr, qwhatnot) which are built for Linux x86_64. Libs are 
cross-build for Windows in both, release and debug versions.

The project knows about host tools and "multiplexing".

Other famous use cases are: building for Android and iOS.

This is supported by qbs. [2]


3. Build something via 1 or 2 and share equal generated artifacts

We're calling rcc once, because we somehow know that the output will be 
the same for all variants of the build products.


This is not supported by qbs at the moment. [3]


Cheers,

Joerg


[1] http://doc.qt.io/qbs/building-applications.html
[2] http://doc.qt.io/qbs/multiplexing.html
[3] 
https://memegenerator.net/img/instances/61770863/im-sorry-do-u-still-love-me-.jpg

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

În ziua de joi, 2 august 2018, la 11:02:30 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 09:52, BogDan Vatra  wrote:
> > 
> > În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> > 
> >>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> >>>  wrote:
> > 
> > […]
> > 
> >>> 
> >>> It will be nice if this feature is mandatory for Qt 6, so let's add it
> >>> to
> >>> 
> >>> 
> >>> your requirements list.
> >> 
> >> 
> >> 
> >> 
> >> Let’s be careful not to add too many requirements upfront or we’ll never
> >> get
 anywhere.
> > 
> > 
> > [...]
> > 
> > Well, if we want to have first class Qt on Android support, this feature
> > is a 
 must. Now, if we can use it also for other platforms that's a
> > bonus.
> 
> Which feature exactly? Creating binaries for multiple targets in on compile
> run? Or also only calling rcc once?
 
> The first one I can see, the second one would be just an optimisation when
> creating multiple binaries.
 
First one.


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

Re: [Development] Qt 6 buildsystem support requirements

[Lars Knoll]

> On 2 Aug 2018, at 09:52, BogDan Vatra  wrote:
> 
> În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
>>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
>>>  wrote:
> […]
>>> 
>>> It will be nice if this feature is mandatory for Qt 6, so let's add it to
>>> 
>>> 
>>> your requirements list.
>> 
>> 
>> 
>> Let’s be careful not to add too many requirements upfront or we’ll never get
>> anywhere.
> 
> [...]
> 
> Well, if we want to have first class Qt on Android support, this feature is a 
> must. Now, if we can use it also for other platforms that's a bonus.

Which feature exactly? Creating binaries for multiple targets in on compile 
run? Or also only calling rcc once?

The first one I can see, the second one would be just an optimisation when 
creating multiple binaries.

Cheers,
Lars

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

În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> >  wrote:
 […]
> > 
> >  It will be nice if this feature is mandatory for Qt 6, so let's add it to
> >  
> > 
> > your requirements list.
> 
> 
> 
> Let’s be careful not to add too many requirements upfront or we’ll never get
> anywhere.
 
[...]

Well, if we want to have first class Qt on Android support, this feature is a 
must. Now, if we can use it also for other platforms that's a bonus.

Cheers,
BogDan.

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