Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Jake Petroules]

Another thing that's very hard to do in other build systems is building Java 
code. The class files emitted by a Java compiler actually vary depending on the 
contents of the Java files themselves.

Imagine you've built a JAR file, and then you add a new anonymous inner class 
within one of your Java source files. The command line invocation to build the 
JAR file needs to be updated to contain the new class file that will result. 
Impossible with qmake/CMake/Makefiles/etc.

Whereas Qbs has sophisticated support exactly for this case: 
https://github.com/qt-labs/qbs/tree/master/share/qbs/modules/java, made 
possible by its dynamic build graph.

On Sep 8, 2016, at 6:52 AM, Bo Thorsen 
> wrote:

Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev:
> The only problem is that you have to run moc on each of the .h files.
Run moc from inside script when you generate header.

Yes, I thought about that at the time as well. While simple enpough, there are 
some complications. You would have to run moc exactly like if it was done by 
the qmake built makefiles, with exactly the same environment and arguments. Not 
impossible, but it does sound brittle. For example different qmake versions 
might do things differently.

Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 08/09/16 14:48, Milian Wolff wrote:

Someone else also told me that this is apparently harder then I thought it is
with CMake, when the name of the output files of a code generator is not
known. It is possible, but far from easy esp. when you don't have control over
the generator script (though one can always use a wrapper). I see now that
having support for this in QBS can be advantageous for the cases where one has
such cases. Thankfully, I never ran into this so far, ever.



All the talk about a 'dynamic build graph' of QBS was about satisfying 
this kind of case in a nice way. That's what makes it interesting to me 
- is that what will make QBS successful?


Thanks,

--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Thiago Macieira]

On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote:
> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
> that? 5.7.1 is very soon in a few weeks. There will be a few months gap
> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
> sometimes it's not tested enough in user(or application developers) side,
> so some regressions or a bit critical issues will be found between 5.8.0
> and 5.8.1. It's good for users to have a more stable release of 5.7.2.
> 
> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
> 
> And I would like to see it becomes a convention for future releases.

It wouldn't be bad, if the release team and merging team can make it work. Our 
concern was that you and Eddy are spending far too much time on doing merges.

-- 
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] Which changes are suitable for 5.6?

[Edward Welbourne]

On Wednesday 07 September 2016 10:26:44 Olivier Goffart wrote:
>> The reason we should limit the changes to critical change is so than
>> "jumping through hoops" gets easier. Every patch we put there instead
>> of in a upper branch makes more work of merging, handling regressions
>> causing by this patch, having to work with an outdated code base.
>>
>> (In fact, I think maybe we should stop merging 5.6. Backporting
>> (chery-pick) proven patches might be more effective.)

Marc Mutz  replied:
> IMO, that's nonsense. I still remember this from 4.8. No thanks.

I can't remember 4.8 - I wasn't here that long ago.
Please share
* what was the process ?
* why was it painful ?  (... as your phrasing indicates it was)

> Why work against the (very good!) revision control system?

One of the nice things about git is that it supports many work-flows.
Using its support for cherry-picking does not "work against" it; indeed,
it's what we primarily do in Gerrit (and rebasing is just mass-produced
cherry-picking).  It also supports merging wonderfully well, of course.
So the real question is: what work-flow works best for us ?

> Anyway, seeing as neither you nor me are doing merges, I guess we
> should let that particular topic in peace for Liang and Eddy to
> comment on, if they so wish.

The branch-management discussion at QtCon decided in fact to go with a
switch to cherry-picking back to LTS once 5.7 closes.  Until then, we'll
be merging 5.6 -> 5.7 -> 5.8 -> dev, which is a painfully long chain,
but we endure it.  Once 5.7 drops out of the chain and 5.9 sneaks in,
however, we'll be merging stable -> release -> dev and cherry-picking
backwards from stable (initially 5.8) to LTS (5.6).  One of the
contributory factors to that choice is just the length of the present
merge chain (which slows propagation of changes); another is the
expectation that conflicts shall become more common when passing over
the dead 5.7 branch (and, eventually, more).  I was part of that
discussion and I am satisfied that this is a sensible way to move
forward - provided I can work out how to hack into sanity-bot the
necessary checks that cherry-picks reference the right sha1s.

If I read the past accurately, it was Marc who had supplied:
>>> Because the LTS is for users who _cannot_ update to newer Qts (for
>>> whatever reason, dropped platforms just being one of them). Pointing
>>> them to a newer Qt where their bug is fixed is not going to help them
>>> one bit.

On the other hand, pointing them to the fix in a newer Qt does, at least
in some cases, offer them the option of patching the version of Qt they
use.  It isn't adequate for all, but it is significantly easier for them
to cherry-pick one (typically self-contained, single-commit) bug-fix
rather than a whole new feature (typically split across several commits,
that may - thanks to the vagaries of Gerrit - have been split up across
a broad span of the git history).

Olivier replied:
>> You could say the same about any new feature.

and Marc followed up with:
> Of course not. A user needs to write code to use a new feature. A bugfix
> affects existing code.

That's actually an interesting way to draw the distinction.  Elsewhere I
see a doc vs code (only one changes in a bug-fix, both in a feature) way
to draw it; this gives a different classification.  There is a general
problem that - in between the changes that are clearly new features and
those that are clearly bug-fixes - there is a broad grey area where it
doesn't really help much to argue about whether the change is a feature
or a fix; it's a change, to be assessed as itself.  Whether it belongs
in a particular branch should be about its suitability for the releases
intended off that branch.

Sometimes we change default behaviour of a system; the client code
doesn't change, but its behaviour does; both the code and the doc
change, so the doc vs code classifier calls this a feature, while the
new code classifier says its a bug-fix.  This is indeed quite apt: some
such changes fix an inappropriate default behaviour, others enable new
ways of using the system.  Whether they're bugs or features isn't really
the important question: whether such a change should go into LTS depends
on whether LTS use-cases are likely to be broken by the change and
whether LTS use-cases are likely to be saved from grief by them.  If we
update the list of cipher-suites used by default in SSL (quite likely we
shall), I don't really care whether you call it a bug-fix or a feature;
I'm fairly sure I'll want it to go into LTS because it'll make client
code work better with the evolving set of ciphers in use by the servers
it'll be talking to.

So let's not get hung up on classifying things as bugs or features;
let's ask what changes should go into LTS.  Changes that are
unequivocally new features shouldn't; changes which unequivocally fix
important bugs that are likely to impact many LTS users should.  The
mess in between does somewhat align with the fuzzy 

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Bo Thorsen]

Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev:

> The only problem is that you have to run moc on each of the .h files.

Run moc from inside script when you generate header.


Yes, I thought about that at the time as well. While simple enpough, 
there are some complications. You would have to run moc exactly like if 
it was done by the qmake built makefiles, with exactly the same 
environment and arguments. Not impossible, but it does sound brittle. 
For example different qmake versions might do things differently.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Network Maintainership Changes

[Edward Welbourne]

On 6 Sep 2016, at 21:05, Richard Moore  wrote:
>> [...] I'd like to nominate Timur as my replacement - he's already
>> spent an inordinate amount of time fixing bugs, to say nothing of
>> adding support for HTTP/2 so I'm sure things are in good hands.
>>
>> https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z
>>
>> On a similar note, I'd like to nominate Jesús Fernández as the
>> maintainer of the QtNetworkAuth module - he wrote it after all!
>>
>> https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z

Morten Sorvig replied:
> +1 to both Timur and Jesús from me.

+1 for both here (disclaimer: I'm in the same team at TQtC),

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Milian Wolff]

On Donnerstag, 8. September 2016 14:03:05 CEST Bo Thorsen wrote:
> Den 08-09-2016 kl. 13:47 skrev Milian Wolff:
> > On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:
> >> Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
>  As an incredibly simple example, make is inherently limited in that it
>  
> > cannot even represent a rule with multiple outputs (there are some
> > workarounds, but they are hacky and rather limited in how they can be
> > applied). And ninja is no magic bullet here either, because that still
> > represents a static build graph, whereas the content of Qbs' build
> > graph
> > can actually change during the execution of the build.
> >>> 
> >>> Can you give an example for why we should care? This may sound
> >>> flame-baity,
> >>> but I'm really truly interested. I simply don't care about my build
> >>> system, as long as it gets the job done without too much hassle (and
> >>> yes,
> >>> that is the case for me personally with cmake), and fast, too (which is
> >>> the case with ninja). See also below.
> >> 
> >> I can answer that because I asked for this feature all the way back at
> >> QtCS in Bilbao.
> >> 
> >> The context I was talking about was code generators. At the time I had
> >> built a code generator that created both the Qt and the PHP side of a
> >> client-server system. It had a single JSON file that described a server
> >> with the available remote methods on it. The output from the C++ code
> >> generator was a .h and .cpp file per method and a single .h and .cpp
> >> that described the server. So on qmake run time you can't know how many
> >> output files you have unless you force the user to run qmake every time
> >> you modify the JSON description.
> >> 
> >> And to make the problem worse, the customer wanted each of the classes
> >> describing a remote call to be qobjects with a Q_OBJECT so a moc run is
> >> required.
> >> 
> >> AFAIK this is impossible to do with both qmake and cmake. Not just hard,
> >> actually impossible.
> > 
> > At least for CMake, I don't think so - if I'm not misunderstanding the
> > problem. You add a target that depends on your .json file, and then
> > whenever that is changed you generate headers. Then you add a dependent
> > target which runs moc. And then you let your actual target depend on that
> > one?
> > 
> >> And the reason is that you can't know until build
> >> time what files you have to run moc on. (Now as a mental exersize,
> >> imagine having multiple server descriptions in a single json file...)
> > 
> > That is not an issue, no? You have one file that you need your targets
> > depend on - the JSON file. If that one changes, the dependent targets
> > must be rebuild.
> > 
> >> It's possible to do in pure make by calling the code generator and
> >> creating a sub make file and then calling make on that. But you can't do
> >> that in any way that supports hitting the build button once in QtCreator.
> >> 
> >> I finally solved this by convincing the customer it was sufficient to
> >> have a qobject base class for the remote calls and live without the meta
> >> object descriptions on those. And yes, this is a very specific case. But
> >> it's an example of something that neither cmake nor qmake can do because
> >> they have a makefile generating step.
> >> 
> >> Maybe this seems more important to me than others because I'm a huge fan
> >> of custom built code generators for stuff like database connections and
> >> client-server communications.
> > 
> > I'm not yet convinced.
> 
> Ok, go try it. Create a simple python or perl script that reads a file.
> The file just has a single number N inside it. And based on N the script
> outputs those files:
> 
> server.h
> method1.h
> method2.h
> ...
> methodN.h
> 
> Inside method1.h you write this:
> 
> #include 
> 
> class Method1 : public QObject {
>Q_OBJECT
> };
> 
> server.h has this:
> 
> #include "method1.h"
> ...
> #include "methodN.h"
> 
> class Server {
> public:
>Method1* call1() { return new Method1; }
>...
>MethodN* callN() { return new MethodN; }
> };
> 
> In main.cpp you instantiate Server.
> 
> The only problem is that you have to run moc on each of the .h files.
> 
> Solution to the problem is only accepted if you can press build one
> single time inside both Visual Studio and Qt Creator and it builds this
> even when you modify the input file and the main.cpp.
> 
> I'm sure there are ways you can make the build call cmake or force a
> build to fail and rebuild, and that's what you can currently do. And
> those all feels annoying when you work on the project.
> 
> You asked why modifying the tree at build time could be necessary. This
> is one of the (probably very few) examples of it.

Someone else also told me that this is apparently harder then I thought it is 
with CMake, when the name of the output files of a code generator is not 
known. It is possible, but far from easy esp. when you don't have control over 

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

On 09/08/2016 02:03 PM, Bo Thorsen wrote:
> Ok, go try it. Create a simple python or perl script that reads a file.
> The file just has a single number N inside it. And based on N the script
> outputs those files:
> 
> server.h
> method1.h
> method2.h
> ...
> methodN.h
> 
> Inside method1.h you write this:
> 
> #include 
> 
> class Method1 : public QObject {
>   Q_OBJECT
> };
> 
> server.h has this:
> 
> #include "method1.h"
> ...
> #include "methodN.h"
> 
> class Server {
> public:
>   Method1* call1() { return new Method1; }
>   ...
>   MethodN* callN() { return new MethodN; }
> };
> 
> In main.cpp you instantiate Server.
> 
> The only problem is that you have to run moc on each of the .h files.
> 
> Solution to the problem is only accepted if you can press build one
> single time inside both Visual Studio and Qt Creator and it builds this
> even when you modify the input file and the main.cpp.

In qbs:

Rule {
inputs: ["metadata"]
fileTags: ["hpp"]
outputArtifacts: {
var p = new Process();
try {
p.exec("path_to_script", ["--list", input.filePath]);
var files = p.readStdout.split("\n");
var artifacts = [];
for (var i in files)
artifacts.push({ filePath: files[i],
 fileTags: ["hpp"]});
return artifacts:
} finally {
p.close();
}
prepare: {
var cmd = new Command("path_to_script",
  ["--generate", input.filePath]);
cmd.description = "creating headers";
return [cmd];
}
}

(This is a somewhat more advanced example in that it is not assumed that
we have a priori knowledge about how the content of the input file
relates to the outputs.)


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Konstantin Tokarev]

08.09.2016, 15:03, "Bo Thorsen" :
> Den 08-09-2016 kl. 13:47 skrev Milian Wolff:
>>  On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:
>>>  Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
>  As an incredibly simple example, make is inherently limited in that it
>
>>  cannot even represent a rule with multiple outputs (there are some
>>  workarounds, but they are hacky and rather limited in how they can be
>>  applied). And ninja is no magic bullet here either, because that still
>>  represents a static build graph, whereas the content of Qbs' build
>>  graph
>>  can actually change during the execution of the build.

  Can you give an example for why we should care? This may sound
  flame-baity,
  but I'm really truly interested. I simply don't care about my build
  system, as long as it gets the job done without too much hassle (and yes,
  that is the case for me personally with cmake), and fast, too (which is
  the case with ninja). See also below.
>>>
>>>  I can answer that because I asked for this feature all the way back at
>>>  QtCS in Bilbao.
>>>
>>>  The context I was talking about was code generators. At the time I had
>>>  built a code generator that created both the Qt and the PHP side of a
>>>  client-server system. It had a single JSON file that described a server
>>>  with the available remote methods on it. The output from the C++ code
>>>  generator was a .h and .cpp file per method and a single .h and .cpp
>>>  that described the server. So on qmake run time you can't know how many
>>>  output files you have unless you force the user to run qmake every time
>>>  you modify the JSON description.
>>>
>>>  And to make the problem worse, the customer wanted each of the classes
>>>  describing a remote call to be qobjects with a Q_OBJECT so a moc run is
>>>  required.
>>>
>>>  AFAIK this is impossible to do with both qmake and cmake. Not just hard,
>>>  actually impossible.
>>
>>  At least for CMake, I don't think so - if I'm not misunderstanding the
>>  problem. You add a target that depends on your .json file, and then whenever
>>  that is changed you generate headers. Then you add a dependent target which
>>  runs moc. And then you let your actual target depend on that one?
>>
>>>  And the reason is that you can't know until build
>>>  time what files you have to run moc on. (Now as a mental exersize,
>>>  imagine having multiple server descriptions in a single json file...)
>>
>>  That is not an issue, no? You have one file that you need your targets 
>> depend
>>  on - the JSON file. If that one changes, the dependent targets must be
>>  rebuild.
>>
>>>  It's possible to do in pure make by calling the code generator and
>>>  creating a sub make file and then calling make on that. But you can't do
>>>  that in any way that supports hitting the build button once in QtCreator.
>>>
>>>  I finally solved this by convincing the customer it was sufficient to
>>>  have a qobject base class for the remote calls and live without the meta
>>>  object descriptions on those. And yes, this is a very specific case. But
>>>  it's an example of something that neither cmake nor qmake can do because
>>>  they have a makefile generating step.
>>>
>>>  Maybe this seems more important to me than others because I'm a huge fan
>>>  of custom built code generators for stuff like database connections and
>>>  client-server communications.
>>
>>  I'm not yet convinced.
>
> Ok, go try it. Create a simple python or perl script that reads a file.
> The file just has a single number N inside it. And based on N the script
> outputs those files:
>
> server.h
> method1.h
> method2.h
> ...
> methodN.h
>
> Inside method1.h you write this:
>
> #include 
>
> class Method1 : public QObject {
>    Q_OBJECT
> };
>
> server.h has this:
>
> #include "method1.h"
> ...
> #include "methodN.h"
>
> class Server {
> public:
>    Method1* call1() { return new Method1; }
>    ...
>    MethodN* callN() { return new MethodN; }
> };
>
> In main.cpp you instantiate Server.
>
> The only problem is that you have to run moc on each of the .h files.

Run moc from inside script when you generate header.

>
> Solution to the problem is only accepted if you can press build one
> single time inside both Visual Studio and Qt Creator and it builds this
> even when you modify the input file and the main.cpp.
>
> I'm sure there are ways you can make the build call cmake or force a
> build to fail and rebuild, and that's what you can currently do. And
> those all feels annoying when you work on the project.
>
> You asked why modifying the tree at build time could be necessary. This
> is one of the (probably very few) examples of it.
>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> Development mailing list
> 

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Bo Thorsen]

Den 08-09-2016 kl. 13:47 skrev Milian Wolff:

On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:

Den 05-09-2016 kl. 20:49 skrev Milian Wolff:

As an incredibly simple example, make is inherently limited in that it


cannot even represent a rule with multiple outputs (there are some
workarounds, but they are hacky and rather limited in how they can be
applied). And ninja is no magic bullet here either, because that still
represents a static build graph, whereas the content of Qbs' build
graph
can actually change during the execution of the build.


Can you give an example for why we should care? This may sound
flame-baity,
but I'm really truly interested. I simply don't care about my build
system, as long as it gets the job done without too much hassle (and yes,
that is the case for me personally with cmake), and fast, too (which is
the case with ninja). See also below.


I can answer that because I asked for this feature all the way back at
QtCS in Bilbao.

The context I was talking about was code generators. At the time I had
built a code generator that created both the Qt and the PHP side of a
client-server system. It had a single JSON file that described a server
with the available remote methods on it. The output from the C++ code
generator was a .h and .cpp file per method and a single .h and .cpp
that described the server. So on qmake run time you can't know how many
output files you have unless you force the user to run qmake every time
you modify the JSON description.

And to make the problem worse, the customer wanted each of the classes
describing a remote call to be qobjects with a Q_OBJECT so a moc run is
required.

AFAIK this is impossible to do with both qmake and cmake. Not just hard,
actually impossible.


At least for CMake, I don't think so - if I'm not misunderstanding the
problem. You add a target that depends on your .json file, and then whenever
that is changed you generate headers. Then you add a dependent target which
runs moc. And then you let your actual target depend on that one?


And the reason is that you can't know until build
time what files you have to run moc on. (Now as a mental exersize,
imagine having multiple server descriptions in a single json file...)


That is not an issue, no? You have one file that you need your targets depend
on - the JSON file. If that one changes, the dependent targets must be
rebuild.


It's possible to do in pure make by calling the code generator and
creating a sub make file and then calling make on that. But you can't do
that in any way that supports hitting the build button once in QtCreator.

I finally solved this by convincing the customer it was sufficient to
have a qobject base class for the remote calls and live without the meta
object descriptions on those. And yes, this is a very specific case. But
it's an example of something that neither cmake nor qmake can do because
they have a makefile generating step.

Maybe this seems more important to me than others because I'm a huge fan
of custom built code generators for stuff like database connections and
client-server communications.


I'm not yet convinced.


Ok, go try it. Create a simple python or perl script that reads a file. 
The file just has a single number N inside it. And based on N the script 
outputs those files:


server.h
method1.h
method2.h
...
methodN.h

Inside method1.h you write this:

#include 

class Method1 : public QObject {
  Q_OBJECT
};

server.h has this:

#include "method1.h"
...
#include "methodN.h"

class Server {
public:
  Method1* call1() { return new Method1; }
  ...
  MethodN* callN() { return new MethodN; }
};

In main.cpp you instantiate Server.

The only problem is that you have to run moc on each of the .h files.

Solution to the problem is only accepted if you can press build one 
single time inside both Visual Studio and Qt Creator and it builds this 
even when you modify the input file and the main.cpp.


I'm sure there are ways you can make the build call cmake or force a 
build to fail and rebuild, and that's what you can currently do. And 
those all feels annoying when you work on the project.


You asked why modifying the tree at build time could be necessary. This 
is one of the (probably very few) examples of it.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Milian Wolff]

On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:
> Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
> >> As an incredibly simple example, make is inherently limited in that it
> >> 
> >> > cannot even represent a rule with multiple outputs (there are some
> >> > workarounds, but they are hacky and rather limited in how they can be
> >> > applied). And ninja is no magic bullet here either, because that still
> >> > represents a static build graph, whereas the content of Qbs' build
> >> > graph
> >> > can actually change during the execution of the build.
> > 
> > Can you give an example for why we should care? This may sound
> > flame-baity,
> > but I'm really truly interested. I simply don't care about my build
> > system, as long as it gets the job done without too much hassle (and yes,
> > that is the case for me personally with cmake), and fast, too (which is
> > the case with ninja). See also below.
> 
> I can answer that because I asked for this feature all the way back at
> QtCS in Bilbao.
> 
> The context I was talking about was code generators. At the time I had
> built a code generator that created both the Qt and the PHP side of a
> client-server system. It had a single JSON file that described a server
> with the available remote methods on it. The output from the C++ code
> generator was a .h and .cpp file per method and a single .h and .cpp
> that described the server. So on qmake run time you can't know how many
> output files you have unless you force the user to run qmake every time
> you modify the JSON description.
> 
> And to make the problem worse, the customer wanted each of the classes
> describing a remote call to be qobjects with a Q_OBJECT so a moc run is
> required.
> 
> AFAIK this is impossible to do with both qmake and cmake. Not just hard,
> actually impossible.

At least for CMake, I don't think so - if I'm not misunderstanding the 
problem. You add a target that depends on your .json file, and then whenever 
that is changed you generate headers. Then you add a dependent target which 
runs moc. And then you let your actual target depend on that one?

> And the reason is that you can't know until build
> time what files you have to run moc on. (Now as a mental exersize,
> imagine having multiple server descriptions in a single json file...)

That is not an issue, no? You have one file that you need your targets depend 
on - the JSON file. If that one changes, the dependent targets must be 
rebuild.

> It's possible to do in pure make by calling the code generator and
> creating a sub make file and then calling make on that. But you can't do
> that in any way that supports hitting the build button once in QtCreator.
> 
> I finally solved this by convincing the customer it was sufficient to
> have a qobject base class for the remote calls and live without the meta
> object descriptions on those. And yes, this is a very specific case. But
> it's an example of something that neither cmake nor qmake can do because
> they have a makefile generating step.
> 
> Maybe this seems more important to me than others because I'm a huge fan
> of custom built code generators for stuff like database connections and
> client-server communications.

I'm not yet convinced.

Bye

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Bo Thorsen]

Den 05-09-2016 kl. 20:49 skrev Milian Wolff:

As an incredibly simple example, make is inherently limited in that it
> cannot even represent a rule with multiple outputs (there are some
> workarounds, but they are hacky and rather limited in how they can be
> applied). And ninja is no magic bullet here either, because that still
> represents a static build graph, whereas the content of Qbs' build graph
> can actually change during the execution of the build.

Can you give an example for why we should care? This may sound flame-baity,
but I'm really truly interested. I simply don't care about my build system, as
long as it gets the job done without too much hassle (and yes, that is the
case for me personally with cmake), and fast, too (which is the case with
ninja). See also below.


I can answer that because I asked for this feature all the way back at 
QtCS in Bilbao.


The context I was talking about was code generators. At the time I had 
built a code generator that created both the Qt and the PHP side of a 
client-server system. It had a single JSON file that described a server 
with the available remote methods on it. The output from the C++ code 
generator was a .h and .cpp file per method and a single .h and .cpp 
that described the server. So on qmake run time you can't know how many 
output files you have unless you force the user to run qmake every time 
you modify the JSON description.


And to make the problem worse, the customer wanted each of the classes 
describing a remote call to be qobjects with a Q_OBJECT so a moc run is 
required.


AFAIK this is impossible to do with both qmake and cmake. Not just hard, 
actually impossible. And the reason is that you can't know until build 
time what files you have to run moc on. (Now as a mental exersize, 
imagine having multiple server descriptions in a single json file...)


It's possible to do in pure make by calling the code generator and 
creating a sub make file and then calling make on that. But you can't do 
that in any way that supports hitting the build button once in QtCreator.


I finally solved this by convincing the customer it was sufficient to 
have a qobject base class for the remote calls and live without the meta 
object descriptions on those. And yes, this is a very specific case. But 
it's an example of something that neither cmake nor qmake can do because 
they have a makefile generating step.


Maybe this seems more important to me than others because I'm a huge fan 
of custom built code generators for stuff like database connections and 
client-server communications.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Oswald Buddenhagen]

On Thu, Sep 08, 2016 at 12:25:02PM +0200, Liang Qi wrote:
> This is mainly because we did heavy refactoring in upstream branches,
>
"upstream" makes no sense whatsoever. merge-wise, it's exactly the wrong
way around. "younger" as used elsewhere in this thread is better.

> for example, rewriting configure system, then any small fix in 5.6
> will trigger a huge conflicts.
> 
yes, it's annoying for the one(s) doing the work, but the fact that it
*has* to be done ensures that it *gets* done. doing cherry-picking is a
virtual guarantee that the LTS becomes a scam.

you should also see things in perspective: how many files merge without
you even noticing it, because the merges are clean?

> Other cases are sth like directories reorganization, class renaming
> and etc, it's very annoying when developers have changes in similar
> places in 5.6 and upper branches.
> 
which is why i'm actually in favor of doing low-risk cleanups and
refactorings on stable branches, or at least shortly before branching
off.

> Best Regards,
> Liang
> 
> 
> 
> > --
> > Alex
> > ___
> > 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] [Qt-creator] [FYI] on gerrit change retargeting requests

[Oswald Buddenhagen]

On Tue, Sep 06, 2016 at 02:56:31PM +0200, Marc Mutz wrote:
> As it is now, not even all @qt.io people know how to do this/that it's 
> possible...
>
of course. why would anyone read the branch creation mails in which we
point out the possibility every single time ... it's not like they have
subjects which look important or something.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.6.2 Snapshot for testing

[Jani Heikkinen]

Hi all,



We have Qt 5.6.2 snapshot for 
testing


Win: http://download.qt.io/snapshots/qt/5.6/5.6.2/553/

Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/489/

Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/418/

src: 
http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/


Packages are based on https://codereview.qt-project.org/#/c/169746/




Unfortunately these aren't yet final Qt 5.6.2 packages because most of change 
files are still missing [☹] But Qt 5.6.2 blocker list is empty (see 
https://bugreports.qt.io/issues/?filter=17829 ) so if nothing really serious 
found during testing we will just update missing change files in the packages & 
release Qt 5.6.2 during next week so please make sure all blockers are visible 
in the blocker list immediately after noticed!


And please make sure change files are in as soon as possible (hoping already 
during this week).


br,

Jani



Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]
 [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] 
  
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] 


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

[Development] QUuid documentation

[Benjamin TERRIER]

Hi,

As of Qt 5.7, QUuid::createUuid() documentation is:

> On any platform other than Windows, this function returns a new UUID with 
> variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device 
> exists, then the numbers used to construct the UUID will be of cryptographic 
> quality, which will make the UUID unique. Otherwise, the numbers of the UUID 
> will be obtained from the local pseudo-random number generator (qrand(), 
> which is seeded by qsrand()) which is usually not of cryptograhic quality, 
> which means that the UUID can't be guaranteed to be unique.
>
> On a Windows platform, a GUID is generated, which almost certainly will be 
> unique, on this or any other system, networked or not.

So according to this there are 3 kinds of UUID:
- Generated by /dev/urandom
- Generated by qrand()
- Generated on Windows OS

The documentation states explicitly that the first type is unique and
that the 2 last types are not unique.

However, my knowledge is that whatever the method one use to generate
your UUID, one can never guarantee its uniqueness. Meaning that the Qt
documentation is falsely guarantying unique UUID and therefore should
be changed.

If anyone can confirm, I'll create a bug report.

BR,

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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Liang Qi]

On 8 September 2016 at 09:36, Alexander Blasche 
wrote:

> 
> From: Marc Mutz 
>
> >On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> >> ** After 5.7 is closed and sanity bot is upgraded (to handle
> >> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> >> responsible for doing the cherrypicking
> >> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> >> verify source ("cherrypicked from") the SHA1
>
> >I'm sorry, but this is nonsense.
>
> I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is
> closed? Since the 5.6 branch will get fewer and fewer patches as the
> strictness of its commits increases I see no reason why 5.6->5.8 could pose
> a problem.
>
> Maybe you sb can elaborate why we have to go to cherry-picking? The notes
> don't say and I wasn't in this QtCon meeting.
>

This is mainly because we did heavy refactoring in upstream branches, for
example, rewriting configure system, then any small fix in 5.6 will trigger
a huge conflicts.

https://codereview.qt-project.org/#/c/163938/

Other cases are sth like directories reorganization, class renaming and
etc, it's very annoying when developers have changes in similar places in
5.6 and upper branches.

Best Regards,
Liang



> --
> Alex
> ___
> 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] Notes on "Managing Qt's branches" session @ QCS 2016

[Alexander Blasche]

From: Marc Mutz 

>On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
>> ** After 5.7 is closed and sanity bot is upgraded (to handle
>> cherry-picking), go into cherrypicking mode for 5.6. Developer is
>> responsible for doing the cherrypicking
>> ** Cherry-picking technicalities need to be figured out: Let sanity bot
>> verify source ("cherrypicked from") the SHA1

>I'm sorry, but this is nonsense.

I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is 
closed? Since the 5.6 branch will get fewer and fewer patches as the strictness 
of its commits increases I see no reason why 5.6->5.8 could pose a problem.

Maybe you sb can elaborate why we have to go to cherry-picking? The notes don't 
say and I wasn't in this QtCon meeting.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Marc Mutz]

On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> ** After 5.7 is closed and sanity bot is upgraded (to handle 
> cherry-picking), go into cherrypicking mode for 5.6. Developer is 
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot 
> verify source ("cherrypicked from") the SHA1

I'm sorry, but this is nonsense. The source control system works by committing 
on the older branches and merging up. Cherry-picking from younger branches 
works against the source control system. We put up with cherry-picking for 
4.8, because there we dealt with separate repositories, but that doesn't make 
is a good model.

There's another aspect to this: I develop part of my patches on gt5.git/5.6 
and the rest on qtbase.git/dev. I guess for most people with non-unlimited 
processing power it will be similar. For sure this is the only way if your 
development focus is on qtbase (and you can't just submit your changes to COIN 
manually).

If I submit from the qt5.git/5.6 built, the changes have gone through testing 
in the stable branch. If I submit from there to younger branches, test 
coverage is not as good, but the point is that the stable branch receives the 
changes tested locally in-situ. If I change this to qt5.git/5.8 and cherry-
pick changes back to 5.6, all local testing will have been done in-situ for 
5.8, and when submitting to 5.6, no in-situ testing has happened locally.

IOW: cherry-picking causes *more* risk to the stable branch than submitting 
there and merging up. I am not convinced that the perceived security of having 
a patch integrated into a younger branch and then submitting it to the older 
branch outweights the loss of test coverage.

If the merging strain is too much, only merge 5.6 up once a fortnight/month.

Currently, it feels like there's

   5.6 -> 5.7
   5.7 -> 5.8
   5.8 -> dev
   5.6 -> 5.7

with maximum speed. That's nice for developers who are splitting changes into 
a bugfix part for 5.6 and a feature part for 5.8/dev, but it hasn't been like 
that in the past and we survived, too. And the git history looked cleaner, too 
:)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Liang Qi]

On 7 September 2016 at 08:37, Friedemann Kleint 
wrote:

> Hi,
>
> the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches
>
> * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of
> problems
>
> ** Strain on COIN which also has release branches
> ** Merging becomes increasingly difficult
> ** Hard to manage for individual developers
>
> * Branches
>
> ** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
>

Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
that? 5.7.1 is very soon in a few weeks. There will be a few months gap
between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
sometimes it's not tested enough in user(or application developers) side,
so some regressions or a bit critical issues will be found between 5.8.0
and 5.8.1. It's good for users to have a more stable release of 5.7.2.

If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.

And I would like to see it becomes a convention for future releases.

Best Regards,
Liang


> ** After 5.7 is closed and sanity bot is upgraded (to handle
> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> verify source ("cherrypicked from") the SHA1
> ** In the future, exact time for closing stable branches will be discussed
> for each one individually
>
> * Submit Policy
>
> ** Target which branch?
>
> ** Long Term Support (5.6) Branch
> *** Initially equal to stable, increasingly strict over time: Fix only
> severe issues, avoid regressions.
>
> *** Bugs: For example, P2 for the first year, P1 for year 2, rest
> Security. Try to further objectify that: Jedrzei + Friedemann
> *** Tests: Fix/stabilize tests itself, add tests
> *** No performance improvements unless really significant
> (relevant/reduces O(n))
> *** Upgrading 3rd party (including WebEngine)
> *** Support new OS versions unless introducing new platforms, no rewrite
> of QPA
> *** No cleanups, positively: -> dev
> *** To aid customers with issues, patches for issues in LTS to be locally
> applied can be provided, but the fixes will be pushed to higher versions of
> Qt.
>
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> The Qt Company GmbH
>
> ___
> 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