From Liang.Qi at qt.io Sun Jul 1 16:04:16 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Sun, 1 Jul 2018 14:04:16 +0000 Subject: [Development] Merge and Integration status report - 2018.07.01 Message-ID: <5FA99143-8ED5-4A44-9B96-E39B06A4FE83@qt.io> Integrations * qt5 dev integration is healthy, last one is June 29 * qt5 5.11 integration is healthy finally again, last one is June 30 Merges * qtbase 5.11->dev is ongoing, https://codereview.qt-project.org/#/c/231959/ , which was blocked about 3 weeks, lots of changes from 5.11. I really want to have this merged as soon as possible. Looks like there is some issue with coin, need someone's help to check, perhaps reboot is needed. -- Liang From edward.welbourne at qt.io Mon Jul 2 11:32:03 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 2 Jul 2018 09:32:03 +0000 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> References: <11510557.QrXFdc88bb@tjmaciei-mobl1>, <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> Message-ID: On 30 Jun 2018, at 18:14, Thiago Macieira wrote: >> I tried to add a change to increase the timeout >> https://codereview.qt-project.org/233691 >> but Liang pointed out that my inspiration is a change by Rohan McGovern back >> in 2012: >> >> dd3e4f1dbe8 tests/auto/network/access/qnetworkreply/test/test.pro (Rohan >> McGovern 2012-05-29 16:20:22 +1000 2) testcase.timeout = 600 # this test >> is slow >> >> So it's highly unlikely that the current CI still obeys this setting. I'm >> assuming therefore that it's hidden somewhere non-obvious (= anywhere not next >> to the test itself) and therefore I'm just bugging you. Lars Knoll (30 June 2018 19:09) > maybe https://codereview.qt-project.org/#/c/233693/ helps with this case. For future reference, here's how to persuade the watch-dog timer to give a test more time, when there's no way to simply reduce the time the test takes: https://codereview.qt-project.org/#/c/226949/1 Eddy, now back from holiday and catching up with e-mail ... From svenn-arne.dragly at qt.io Mon Jul 2 12:56:02 2018 From: svenn-arne.dragly at qt.io (Svenn-Arne Dragly) Date: Mon, 2 Jul 2018 12:56:02 +0200 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> Message-ID: On 06/20/2018 01:01 PM, Tor Arne Vestbø wrote: > Good point, I was imagining it used only to verify style, not to auto-format. Still, starting out with a few non-controversial rules would be a good thing. I agree. For instance, it is clear from the patch discussion[1] that line length/column count is controversial. I think it would be best to set this to 0 for now to be able to move forward and get the benefits of clang-format for all the other things that we do agree on. Setting it to 0 means that clang-format will respect your decisions about line length unless you contradict other rules. There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. Svenn-Arne [1] https://codereview.qt-project.org/#/c/233051/ [2] https://github.com/qt-creator/qt-creator/blob/master/dist/clangformat/.clang-format From Tor.arne.Vestbo at qt.io Mon Jul 2 13:35:00 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Mon, 2 Jul 2018 11:35:00 +0000 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> Message-ID: > On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote: > > There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. I oppose mandating this style, through clang-format or otherwise. Tor Arne From lars.knoll at qt.io Mon Jul 2 16:49:06 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 2 Jul 2018 14:49:06 +0000 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> Message-ID: <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> > On 2 Jul 2018, at 13:35, Tor Arne Vestbø wrote: > > >> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote: >> >> There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. > > I oppose mandating this style, through clang-format or otherwise. Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. I didn't know that creator had a clang-format file. I had a quick chat with some of the team here in Berlin, and the file is a result of discussions they had some time ago. They are apparently mostly happy with the style. I would really like to go with one format file for all of Qt, so why not use the one from Creator? And just to repeat: The reasons I want some automated formatting and checking is to remove manual work in the reviewing process. It'll help both the people reviewing as well as making it easier for new contributors to create patches that are consistent with our coding style. Longer term, I want to have as much checking as possible (e.g. compile checking and maybe even auto testing) happening before the manual code review is being done. Cheers, Lars From Tor.arne.Vestbo at qt.io Mon Jul 2 16:52:52 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Mon, 2 Jul 2018 14:52:52 +0000 Subject: [Development] clang-format In-Reply-To: <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> Message-ID: > On 2 Jul 2018, at 16:49, Lars Knoll wrote: > > >> On 2 Jul 2018, at 13:35, Tor Arne Vestbø wrote: >> >> >>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote: >>> >>> There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. >> >> I oppose mandating this style, through clang-format or otherwise. > > Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. Why not ease into this with the non-controversial style-rules first? Tor Arne From thiago.macieira at intel.com Tue Jul 3 05:55:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 2 Jul 2018 20:55:30 -0700 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> References: <11510557.QrXFdc88bb@tjmaciei-mobl1> <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> Message-ID: <1654368.X5A7lbEcUX@tjmaciei-mobl1> On Saturday, 30 June 2018 10:09:11 PDT Lars Knoll wrote: > Hi Thiago, > > maybe https://codereview.qt-project.org/#/c/233693/ helps with this case. It did help some. It went from PASS : tst_QComplexText::bidiTest(line #201771 (LTR) to PASS : tst_QComplexText::bidiTest(line #456371 (RTL)) So we doubled the performance. But it wasn't enough. Trying Eddy's suggestion instead: https://codereview.qt-project.org/233794 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From a.rehn at menlosystems.com Tue Jul 3 09:29:00 2018 From: a.rehn at menlosystems.com (Arno Rehn) Date: Tue, 3 Jul 2018 09:29:00 +0200 Subject: [Development] QWebChannel pure C++14 client In-Reply-To: <3711460.0QcWIJXMHT@tjmaciei-mobl1> References: <7a8b1730-2cd1-b810-6d58-8a40198bd6bf@menlosystems.com> <3711460.0QcWIJXMHT@tjmaciei-mobl1> Message-ID: Am 27.06.2018 um 16:55 schrieb Thiago Macieira: > On Wednesday, 27 June 2018 01:24:53 PDT Arno Rehn wrote: >> FYI: We've now also completed the QWebChannel C++14 client: >> https://github.com/MenloSystems/webchannelpp >> >> It's header-only and depends only on the C++ JSON library by Niels >> Lohmann (https://github.com/nlohmann/json). > > You forgot the Asio dependency, which makes it not pure C++. The asio based transport is just an example. You can implement whatever transport backend you like (pretty much like in QWebChannel proper). I've chosen to use asio as an example because it's header-only, too. You only have to additionally link against your platform's socket library. Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 From lars.knoll at qt.io Tue Jul 3 10:05:47 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 3 Jul 2018 08:05:47 +0000 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: <1654368.X5A7lbEcUX@tjmaciei-mobl1> References: <11510557.QrXFdc88bb@tjmaciei-mobl1> <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> <1654368.X5A7lbEcUX@tjmaciei-mobl1> Message-ID: > On 3 Jul 2018, at 05:55, Thiago Macieira wrote: > > On Saturday, 30 June 2018 10:09:11 PDT Lars Knoll wrote: >> Hi Thiago, >> >> maybe https://codereview.qt-project.org/#/c/233693/ helps with this case. > > It did help some. It went from > > PASS : tst_QComplexText::bidiTest(line #201771 (LTR) > > to > > PASS : tst_QComplexText::bidiTest(line #456371 (RTL)) > > So we doubled the performance. But it wasn't enough. Are you sure you already have the fix (it went into 5.11 first)? Because with the patch, you shouldn't see those 'line #xxx' things at all anymore. bidiTest should just report one single line. Cheers, Lars > > Trying Eddy's suggestion instead: > https://codereview.qt-project.org/233794 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From cavendish.qi at gmail.com Tue Jul 3 10:09:15 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 3 Jul 2018 10:09:15 +0200 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: References: <11510557.QrXFdc88bb@tjmaciei-mobl1> <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> <1654368.X5A7lbEcUX@tjmaciei-mobl1> Message-ID: On Tue, 3 Jul 2018 at 10:05, Lars Knoll wrote: > > On 3 Jul 2018, at 05:55, Thiago Macieira > wrote: > > > > On Saturday, 30 June 2018 10:09:11 PDT Lars Knoll wrote: > >> Hi Thiago, > >> > >> maybe https://codereview.qt-project.org/#/c/233693/ helps with this > case. > > > > It did help some. It went from > > > > PASS : tst_QComplexText::bidiTest(line #201771 (LTR) > > > > to > > > > PASS : tst_QComplexText::bidiTest(line #456371 (RTL)) > > > > So we doubled the performance. But it wasn't enough. > > Are you sure you already have the fix (it went into 5.11 first)? Because > with the patch, you shouldn't see those 'line #xxx' things at all anymore. > bidiTest should just report one single line. > > > Latest qtbase 5.11->dev merge is just integrated about 10-20 minutes ago this morning. -- Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue Jul 3 10:26:21 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 3 Jul 2018 08:26:21 +0000 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> Message-ID: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> On 2 Jul 2018, at 16:52, Tor Arne Vestbø > wrote: On 2 Jul 2018, at 16:49, Lars Knoll > wrote: On 2 Jul 2018, at 13:35, Tor Arne Vestbø > wrote: On 2 Jul 2018, at 12:56, Svenn-Arne Dragly > wrote: There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. I oppose mandating this style, through clang-format or otherwise. Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. Why not ease into this with the non-controversial style-rules first? clang-format will produce one way how the output is formatted. It will reformat your sources a certain way with less definitions in the file as well. So it's most likely better to have more rules defined as it'll give something closer to our implicitly used coding style. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tor.arne.Vestbo at qt.io Tue Jul 3 12:13:06 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 3 Jul 2018 10:13:06 +0000 Subject: [Development] clang-format In-Reply-To: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> Message-ID: <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> > On 3 Jul 2018, at 10:26, Lars Knoll wrote: > >> On 2 Jul 2018, at 16:52, Tor Arne Vestbø wrote: >> >> >> >>> On 2 Jul 2018, at 16:49, Lars Knoll wrote: >>> >>> >>>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø wrote: >>>> >>>> >>>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote: >>>>> >>>>> There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. >>>> >>>> I oppose mandating this style, through clang-format or otherwise. >>> >>> Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. >> >> Why not ease into this with the non-controversial style-rules first? > > clang-format will produce one way how the output is formatted. It will reformat your sources a certain way with less definitions in the file as well. So it's most likely better to have more rules defined as it'll give something closer to our implicitly used coding style. Really?? That sounds like a key feature, I’m surprised clang-format doesn’t allow it to leave code untouched. If that’s the case then I’m not convinced this exercise is worth the churn. I thought we were going to run it as a fancy style bot, complaining if the code isn’t per the format-file, but allowing us to ignore it if we feel the tailored code-formatting is better? Doesn’t this mean the bot will complain a lot? We already have a style guide. Introducing clang-format to the mix does two things: 1. Formalizes the style guide (to a certain degree) 2. Introduces new style rules The second point was new to me, I was under the impression we were only going to use it as a convenient tool to improve #1. Tor Arne From svenn-arne.dragly at qt.io Tue Jul 3 12:42:39 2018 From: svenn-arne.dragly at qt.io (Svenn-Arne Dragly) Date: Tue, 3 Jul 2018 12:42:39 +0200 Subject: [Development] clang-format In-Reply-To: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> Message-ID: <19a9cf4f-3285-f1be-fbe3-c849de9dc42f@qt.io> On 07/03/2018 10:26 AM, Lars Knoll wrote: >> On 2 Jul 2018, at 16:52, Tor Arne Vestbø > > > wrote: >> > >> > >> > >> >> On 2 Jul 2018, at 16:49, Lars Knoll > >> > wrote: >> >> >> >> >> >>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø > >>> > wrote: >> >>> >> >>> >> >>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly > >>>> > wrote: >> >>>> >> >>>> There are also many nice options set in the clang-format config found in Qt >> >>>> Creator's sources[2] which I think are interesting. For instance, >> >>>> "BinPackParameters: false" and "BinPackArguments: false" makes sure you to >> >>>> either put all arguments on one line or give if arguments will have one >> >>>> line each. This might be in the controversial category, but it is nice to >> >>>> enable while developing. It makes clang-format reflow the code consistently >> >>>> just by moving a single argument to a new line and running clang-format >> >>>> afterwards. >> >>> >> >>> I oppose mandating this style, through clang-format or otherwise. >> >> >> >> Having a common style that we start following is worth something. And yes, >> >> everybody will always find some details he won't like. So we won't get >> >> anywhere if everybody wants it exactly his way. >> > >> > Why not ease into this with the non-controversial style-rules first? >> >> clang-format will produce one way how the output is formatted. It will reformat >> your sources a certain way with less definitions in the file as well. So it's >> most likely better to have more rules defined as it'll give something closer to >> our implicitly used coding style. >> >> Cheers, >> Lars >> Not necessarily. With fewer options set, clang-format does leave some things as is, so the output is not always the same. For instance, if you leave "BinPackArguments" unset and set "ColumnLimit: 0", clang-format will respect your choices regarding argument placement. The following code is for instance kept intact in that case:     auto result = myFunction(arg1, arg2,                              argument3, arg4, argument5,                              0, nullptr); And similarly, this is kept intact:     auto result = myFunction(arg1, arg2, argument3, arg4,                              argument5, 0, nullptr); Setting "BinPackArguments: false" or "ColumnLimit: 100" does on the other hand make clang-format reformat the above function call accordingly. I agree with you, Tor Arne. I think it is better to start out with a config with only uncontroversial settings enabled. This already gets us pretty far and we'll have fewer arguments about style. And to be clear, I also don't want to mandate setting "BinPackArguments: false". I wanted to mention it because I found it nice to enable locally, even though it is far from perfect. If anything should be mandated with regards to argument placement, it should probably be more sophisticated or simply rely on a fixed column count. However, a comprehensive clang-format config would be the best in the long run. So even though I think we should start with a minimal config, I also think we should start discussing the controversial options in separate threads/code reviews. Going through the different options in Creator's config is a good start. Svenn-Arne From philwave at gmail.com Tue Jul 3 13:06:13 2018 From: philwave at gmail.com (Philippe) Date: Tue, 03 Jul 2018 13:06:13 +0200 Subject: [Development] clang-format In-Reply-To: <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> References: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> Message-ID: <20180703130612.303C.6F0322A@gmail.com> > Really?? That sounds like a key feature, I’m surprised clang-format doesn’t allow it to leave code untouched. As already mentionned, there is always the option to tag code sections: // clang-format off ... // clang-format on > I thought we were going to run it as a fancy style bot, complaining if > the code isn’t per the format-file, but allowing us to ignore it if we > feel the tailored code-formatting is better? Doesn’t this mean the bot > will complain a lot? If there is the need for some human intervention after a bot work, for code formatting purposes, this would defeat any productivity goal. Philippe On Tue, 3 Jul 2018 10:13:06 +0000 Tor Arne Vestbø wrote: > > > > On 3 Jul 2018, at 10:26, Lars Knoll wrote: > > > >> On 2 Jul 2018, at 16:52, Tor Arne Vestbø wrote: > >> > >> > >> > >>> On 2 Jul 2018, at 16:49, Lars Knoll wrote: > >>> > >>> > >>>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø wrote: > >>>> > >>>> > >>>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote: > >>>>> > >>>>> There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. > >>>> > >>>> I oppose mandating this style, through clang-format or otherwise. > >>> > >>> Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. > >> > >> Why not ease into this with the non-controversial style-rules first? > > > > clang-format will produce one way how the output is formatted. It will reformat your sources a certain way with less definitions in the file as well. So it's most likely better to have more rules defined as it'll give something closer to our implicitly used coding style. > > Really?? That sounds like a key feature, I’m surprised clang-format doesn’t allow it to leave code untouched. > > If that’s the case then I’m not convinced this exercise is worth the churn. I thought we were going to run it as a fancy style bot, complaining if the code isn’t per the format-file, but allowing us to ignore it if we feel the tailored code-formatting is better? Doesn’t this mean the bot will complain a lot? > > We already have a style guide. Introducing clang-format to the mix does two things: > > 1. Formalizes the style guide (to a certain degree) > 2. Introduces new style rules > > The second point was new to me, I was under the impression we were only going to use it as a convenient tool to improve #1. > > Tor Arne > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Jul 3 13:42:09 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 3 Jul 2018 11:42:09 +0000 Subject: [Development] clang-format In-Reply-To: <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> Message-ID: <2512AC91-B6BF-4B9F-8183-8582ED2B3B47@qt.io> On 3 Jul 2018, at 12:13, Tor Arne Vestbø > wrote: On 3 Jul 2018, at 10:26, Lars Knoll > wrote: On 2 Jul 2018, at 16:52, Tor Arne Vestbø > wrote: On 2 Jul 2018, at 16:49, Lars Knoll > wrote: On 2 Jul 2018, at 13:35, Tor Arne Vestbø > wrote: On 2 Jul 2018, at 12:56, Svenn-Arne Dragly > wrote: There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. I oppose mandating this style, through clang-format or otherwise. Having a common style that we start following is worth something. And yes, everybody will always find some details he won't like. So we won't get anywhere if everybody wants it exactly his way. Why not ease into this with the non-controversial style-rules first? clang-format will produce one way how the output is formatted. It will reformat your sources a certain way with less definitions in the file as well. So it's most likely better to have more rules defined as it'll give something closer to our implicitly used coding style. Really?? That sounds like a key feature, I’m surprised clang-format doesn’t allow it to leave code untouched. If that’s the case then I’m not convinced this exercise is worth the churn. I thought we were going to run it as a fancy style bot, complaining if the code isn’t per the format-file, but allowing us to ignore it if we feel the tailored code-formatting is better? Doesn’t this mean the bot will complain a lot? The idea is to only run it on lines that the change touches anyway. That is apparently possible, so you will not get a full reformat of the file(s) you touched. We already have a style guide. Introducing clang-format to the mix does two things: 1. Formalizes the style guide (to a certain degree) 2. Introduces new style rules The second point was new to me, I was under the impression we were only going to use it as a convenient tool to improve #1. It does formalise the rules, something I think is a good thing. To some extent it might introduce new ones, but the idea was to aim for a format file that is very close to our existing rules. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tor.arne.Vestbo at qt.io Tue Jul 3 14:09:37 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 3 Jul 2018 12:09:37 +0000 Subject: [Development] clang-format In-Reply-To: <2512AC91-B6BF-4B9F-8183-8582ED2B3B47@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> <33ECB006-3F96-4F50-AC26-BCD908F79145@qt.io> <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> <2512AC91-B6BF-4B9F-8183-8582ED2B3B47@qt.io> Message-ID: On 3 Jul 2018, at 13:42, Lars Knoll wrote: > > To some extent it might introduce new ones, but the idea was to aim for a format file that is very close to our existing rules. It seems the extent is wider than first outlined. And even if it’s very close to the existing rules, those rules will now be strictly enforced, instead of leaving it up to developers to use common sense. The absolute worst thing about PEP8 e.g. is its strict line length rule, which forces you to awkwardly wrap code in weird places or split lines up into multiple statements, just for the sake of being able to read the code on a 80s terminal. Tor Arne From dominik.holland at pelagicore.com Tue Jul 3 14:12:08 2018 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Tue, 3 Jul 2018 14:12:08 +0200 Subject: [Development] clang-format In-Reply-To: <20180703130612.303C.6F0322A@gmail.com> References: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> <20180703130612.303C.6F0322A@gmail.com> Message-ID: <27b8b0a4-c20e-5852-9949-cd0afeb977df@pelagicore.com> >> I thought we were going to run it as a fancy style bot, complaining if >> the code isn't per the format-file, but allowing us to ignore it if we >> feel the tailored code-formatting is better? Doesn't this mean the bot >> will complain a lot? > If there is the need for some human intervention after a bot work, for > code formatting purposes, this would defeat any productivity goal. Not necessarily. In one of our previous project we patched the Sanity Bot to run clang-format over the patch (only the patch, not the complete files) and provide the complains as bot comment. You could ignore it, or just copy and paste one command from the comment and it would fix all the issues in your patch (again only the patch, not the complete file). Just pasting a single command doesn't sound like it would defeat any productivity goal to me. Dominik From Shawn.Rutledge at qt.io Tue Jul 3 14:54:20 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 3 Jul 2018 12:54:20 +0000 Subject: [Development] clang-format In-Reply-To: <27b8b0a4-c20e-5852-9949-cd0afeb977df@pelagicore.com> References: <1DCCA7D9-0F8E-4F02-AE2B-40A76DEEB211@qt.io> <76E4B3DF-5247-4E84-9DE9-F8FF37306D53@qt.io> <20180703130612.303C.6F0322A@gmail.com> <27b8b0a4-c20e-5852-9949-cd0afeb977df@pelagicore.com> Message-ID: <820C795C-DFAD-4057-8D6D-5F54DF3A4D19@qt.io> > On 3 Jul 2018, at 14:12, Dominik Holland wrote: > > >>> I thought we were going to run it as a fancy style bot, complaining if >>> the code isn't per the format-file, but allowing us to ignore it if we >>> feel the tailored code-formatting is better? Doesn't this mean the bot >>> will complain a lot? >> If there is the need for some human intervention after a bot work, for >> code formatting purposes, this would defeat any productivity goal. > > Not necessarily. In one of our previous project we patched the Sanity > Bot to run clang-format over the patch (only the patch, not the complete > files) and provide the complains as bot comment. > You could ignore it, or just copy and paste one command from the comment > and it would fix all the issues in your patch (again only the patch, not > the complete file). > > Just pasting a single command doesn't sound like it would defeat any > productivity goal to me. I think the way to start is with a commit hook to run clang-format on each patch, in a way which will reformat only changed lines and ignore other lines in the file. After we try that for a while we’ll see whether we like the results. From frederik.gladhorn at qt.io Tue Jul 3 16:18:31 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 03 Jul 2018 16:18:31 +0200 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <2249292.50tEjXmN5E@frederik-thinkcentre-m93p> On onsdag 20. juni 2018 13.01.10 CEST Tor Arne Vestbø wrote: > On 20 Jun 2018, at 12:13, Lars Knoll wrote: > > > > > I can’t see how clang-format will make you jump through any sort of hoops. > > Creator already has a hook for doing it on file saving time afaik, > > git-clang-format will clean up your change from the command line. > > Good point, I was imagining it used only to verify style, not to > auto-format. Still, starting out with a few non-controversial rules would > be a good thing. For now we're trying to get the format definition file into qt5 at all. Once we have a file we agree on (and I'd be happy to see it evolve, it's in git, so please just contribute everyone), we can decide how to use it. I see several things that would make sense. 1) Make it easy to use locally. That is mostly the case, just run: $ git clang-format And the lines you changed will be reformatted. 2) It's relatively easy to have a commit hook that complains or runs clang- format for you. 3) Make it part of the sanity bot with a nice message explaining that it's possible to use clang-format and ask contributors to use it (with neutral or -1 effect). Cheers, Frederik > Tor Arne > > > > > > > Lars > > > > > >> On 20 Jun 2018, at 11:52, Tor Arne Vestbø wrote: > >> > >> How about we also start with only one or two obvious rules that everyone > >> agrees on? I don’t want Qt development to turn into Python PEP8 type > >> rigid rules that makes you jump through a million hoops. If the latter > >> is the goal here then I’m against enforcing clang-format, and it should > >> be implemented as a bot that just warns, similar to the current style > >> bot. > >> - Tor Arne > >> > >> > >>> On 20 Jun 2018, at 11:21, André Pönitz wrote: > >>> > >>> > >>>> On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote: > >>>> > >>>> > >>>> > >>>>> On 19 Jun 2018, at 18:19, Ville Voutilainen > >>>>> wrote: > >>>>> > >>>>> On 19 June 2018 at 19:13, Philippe wrote: > >>>>> > >>>>>>> For the above reasons I'd lean towards not running it globally and > >>>>>>> just using it on new changes. > >>>>>> > >>>>>> > >>>>>> +1, based on my clang-format experience on a big application. > >>>>>> > >>>>>> BTW, keep in mind that you can disable clang-format on code > >>>>>> sections with: > >>>>>> > >>>>>> // clang-format off // clang-format on > >>>>> > >>>>> > >>>>> When I last experienced a large-scale clang-format reformat, it > >>>>> really hurt development during the churn. We should somehow manage > >>>>> to do it during a time when there aren't many pending patches in the > >>>>> pipeline. I'm not concerned about git-blame; that has never been a > >>>>> problem after reformats. However, I do not care about indentation > >>>>> nor do I want to spend time on it either way, it has no actual > >>>>> effect on readability and maintainability of code, and consistency > >>>>> outside the file you're in has never mattered to me one bit. > >>>>> > >>>>> IOW, I'm not opposed to reformats and auto-checking of clang-format > >>>>> (or even hooking it), but I do not see it as a thing with all that > >>>>> great return-of-investment. > >>>> > >>>> > >>>> It helps in that you do not need to point those things out in code > >>>> reviews, and that I (and others) won’t even create changes with wrong > >>>> formatting that I’ll need to fix up later on. It’s part of a larger > >>>> story, where I would like to get as much automatic checking of changes > >>>> done before humans start reviewing. > >>> > >>> > >>> It's also a cultural thing. > >>> > >>> Quite a few people seem to take less offense from a "Your formatting is > >>> bad" when the comment comes from a bot than when it comes from a human. > >>> > >>> > >>> > >>>> One idea could be to introduce this incrementally. Let’s first start > >>>> off with enforcing it for new changes. Then we run it globally over > >>>> the code base shortly before Qt 6.0 is being released. At that time > >>>> merges shouldn’t be as much of a problem (as we’ll probably > >>>> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will > >>>> be properly formatted (due to the earlier hook). > >>> > >>> > >>> Incrementally sounds good to me. > >>> > >>> Still I am a bit of a fence here. So far I've seen a couple of auto- > >>> formatting attempts biting back, so I thinl it would help to convince > >>> me > >>> to see the kind of changes that would happen first before deciding > >>> on the global change. > >>> > >>> Andre' > >>> _______________________________________________ > >>> Development mailing list > >>> Development at qt-project.org > >>> http://lists.qt-project.org/mailman/listinfo/development > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Jul 3 16:37:25 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 3 Jul 2018 14:37:25 +0000 Subject: [Development] Coding style: space after comma Message-ID: I notice that our coding style [0] doesn't actually say out loud that we expect a space after each comma (and none before). Its sole mention of comma is that it goes at a line-end, unlike operators at line-start, on a continued line. Yet the Qt code-base is mostly consistent about this and I've seen other reviewers ask for it, so I understand it to be part of our de facto style. I also favour it. [0] https://wiki.qt.io/Qt_Coding_Style I propose to follow (under "Whitespace") the list item * Surround binary operators with spaces with * Leave a space after each comma Any objections, or improved wordings ? (I omit "none before" in light of the still-controversial constructor form, Derived:Derived(Type arg, Mode um, Form ent) : Base(arg) , mem(um) , ber(ent) {} discussed some time ago, IIRC inconclusively.) Eddy. From thiago.macieira at intel.com Tue Jul 3 16:58:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 3 Jul 2018 07:58:32 -0700 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: References: <11510557.QrXFdc88bb@tjmaciei-mobl1> <1654368.X5A7lbEcUX@tjmaciei-mobl1> Message-ID: <2259267.v3tI36dVdR@tjmaciei-mobl1> On Tuesday, 3 July 2018 01:05:47 PDT Lars Knoll wrote: > Are you sure you already have the fix (it went into 5.11 first)? Because > with the patch, you shouldn't see those 'line #xxx' things at all anymore. > bidiTest should just report one single line. *facepalm* Right, this was in dev... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From resurrection at centrum.cz Tue Jul 3 20:13:52 2018 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Tue, 03 Jul 2018 20:13:52 +0200 Subject: [Development] =?utf-8?q?clang-format?= Message-ID: <20180703201352.AAE1C88A@centrum.cz> Interesting discussion about using clang-format Qt wide. As someone who implemented something like that in a project (of smaller size than Qt, but not all that small) some points:   - clang-format virtually annihilates A LOT of manual work. It might not seem like much but I have measured it and even had to work on two projects simultaneously where only one had clang-format. It was staggering how much time is spent on formatting when done manually. And how much it annoys you since you KNOW it can be done for you, automatically and always correctly. It also speed things up because if you make a formatting mistake it will be corrected as soon as you save the file in Qt Creator. So you don't bother correcting it, you just go on typing or hit ctrl+s if it annoys you to see it. You will get seriously addicted to that. It is really quite liberating.   - I have read many concerns here about loss of immediate history, that clang-format does not get it always right etc. Well we had those too but one thing beats them all - free consistency. I could hardly believe it but even though I did not like all of the rules we put in it the fact that they were consistent everywhere made reading the code far easier than before. You could not be surprised, you knew where will everything be. Whether it was includes and their ordering (the epic battles about that in pre-clang-format era...), alignment, wrapping, you name it. Once you could rely on the fact that it will be the same everywhere you suddenly did not have to focus on formatting which (again surprisingly) took a lot of code review time for all parties.   - Continuous integration. I cannot stress this one enough. Make it a standard in the repo, make everyone enable it in Qt Creator, make a git hook and make it part of the build. Our CI failed when someone committed incorrectly formatted file telling him as much even before compilation or anything. It happened rarely as most people used the git hook but still.   - Most people will be sceptical until they start working with it. I guess this is a given for any new technology or approach. I know I was. But I am yet to come by a colleague that would complain about it or who would want to remove it. It might not be perfect but the benefits far outweigh any issues.   And on more practical note:   - We converted all sources at once and it has not caused any problems - it's just formatting anyhow. - Some files (very few) turned out to be somewhat broken but the reason for that was that they were curiously formatted in the first place. We fixed those as they were encountered. It generated negligible amount of extra "work" (as mentioned hitting Enter for new line and saving file to reformat typically was the trick).   I became a huge fan of clang-format thanks to making my work a lot more pleasant and less tedious experience. It might not seem like much but it really makes a big difference in daily work. I really hope it will be adopted Qt-wide.   My 2 cents and I would gladly answer any questions about practicalities as someone who did pretty much all of it from converting all sources to implementing the git hook and CI stuff.   Best wishes, Michael Vlach Software Engineer NCR -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Wed Jul 4 00:12:35 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Tue, 3 Jul 2018 22:12:35 +0000 Subject: [Development] Merge and Integration status report - 2018.07.04 Message-ID: <0674DC67-961C-48F3-ADBE-137115C14FD2@qt.io> Merges * qtbase 5.11->dev, https://codereview.qt-project.org/#/c/231959/ finally got merged after blocked about 3 weeks. A new round is ongoing, https://codereview.qt-project.org/#/c/233803/ Integrations * qt5 dev, last one is June 29, 4 days ago. A new one is at https://codereview.qt-project.org/#/c/233675/ , but wait for other provisioning changes. * * Issue: https://bugreports.qt.io/browse/QTBUG-69280 qtlocation: declarative_ui crash. Haven’t have time to check it yet. * qt5 5.11 is healthy, last one is yesterday During summer holiday, please help to keep an eye on merges at https://codereview.qt-project.org/#/q/owner:qt_forward_merge_bot%2540qt-project.org+status:open,n,z and integrations at https://codereview.qt-project.org/#/q/owner:qt_submodule_update_bot%2540qt-project.org+status:open,n,z . -- Liang From martonmiklosqdev at gmail.com Wed Jul 4 22:11:16 2018 From: martonmiklosqdev at gmail.com (Miklos Marton) Date: Wed, 4 Jul 2018 22:11:16 +0200 Subject: [Development] [qtserialbus]PeakCAN plugin support for macOS Message-ID: <57ef8a2a-5824-c87c-57b8-a23f2b9fa5d6@gmail.com> Hello all, We are using the qtserialbus for developing some internal tools communicating with devices via PEAK CAN adapters and there were some interest of getting it working on macOS. The PEAK Systems does not offer official API for their products on MAC, however there is a 3rd party developer who builds an API which is --nearly-- compatible with the pcanbasic API: http://www.mac-can.com/ I would like to raise some discussion on them before submitting a patch. - Are there any interest of upstreaming such a patch? I have came over the following issues with getting it working on MAC: - The library named differently (PCBUSB vs. pcanbasic). This issue can be easily resolved by a simple ifdefs. I have consulted with the author an he said he is not planning to change the name to pcanbasic (since it is a different library). - The official pcanbasic API uses some non fixed sized types (DWORD, long etc.) and the same types were used in the PCBUSB too. The ID fields of the CAN messages (and another data fields int the API) defined as DWORD which is unsigned long in the PCBUSB headers. This type is compiled to 64 bit wide integer on 64 bit macOS , while in the peakcan_symbols_p.h it is defined as a quint32. This could be also workarounded by some ifdefs. Thank you for your feedback in advance! -- Best regards, Miklos Marton -------------- next part -------------- An HTML attachment was scrubbed... URL: From aha_1980 at gmx.de Wed Jul 4 22:21:47 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Wed, 4 Jul 2018 22:21:47 +0200 Subject: [Development] [qtserialbus]PeakCAN plugin support for macOS In-Reply-To: <57ef8a2a-5824-c87c-57b8-a23f2b9fa5d6@gmail.com> References: <57ef8a2a-5824-c87c-57b8-a23f2b9fa5d6@gmail.com> Message-ID: <4eb130df-cb9d-d39f-8ee5-7558e9847b3f@gmx.de> Hi Miklos, thanks for your interest in QtSerialBus! > - Are there any interest of upstreaming such a patch? Of course. We don't have any macOS support for now, so this would greatly improve the situation. > - The library named differently (PCBUSB vs. pcanbasic). This issue can > be easily resolved by a simple ifdefs. I have consulted with the > author an he said he is not planning to change the name to pcanbasic > (since it is a different library). That would be fine with me. > - The official pcanbasic API uses some non fixed sized types (DWORD, > long etc.) and the same types were used in the PCBUSB too. The ID > fields of the CAN messages (and another data fields int the API) > defined as DWORD which is unsigned long in the PCBUSB headers. This > type is compiled to 64 bit wide integer on 64 bit macOS > , > while in the peakcan_symbols_p.h > > it is defined as a quint32. This could be also workarounded by some > ifdefs. Maybe we can introduce a special type for this, that maps to the different OS specific types - could be best decided when we have actual code to discuss (in Gerrit). Are you already familiar with code submission to Qt? If not, please read http://wiki.qt.io/Gerrit_Introduction first and ask here if you have further questions. If you have specific questions to QtSerialBus you can mail me directly. It may just take some time as I'm in vacation, and I can't support you with macOS specific issues, but otherwise I'm glad to help. Regards, André Am 04.07.2018 um 22:11 schrieb Miklos Marton: > Hello all, > > We are using the qtserialbus for developing some internal tools > communicating with devices via PEAK CAN adapters and there were some > interest of getting it working on macOS. > > The PEAK Systems does not offer official API for their products on MAC, > however there is a 3rd party developer who builds an API which is > --nearly-- compatible with the pcanbasic API: > > http://www.mac-can.com/ > > I would like to raise some discussion on them before submitting a patch. > > - Are there any interest of upstreaming such a patch? > > I have came over the following issues with getting it working on MAC: > > - The library named differently (PCBUSB vs. pcanbasic). This issue can > be easily resolved by a simple ifdefs. I have consulted with the author > an he said he is not planning to change the name to pcanbasic (since it > is a different library). > > - The official pcanbasic API uses some non fixed sized types (DWORD, > long etc.) and the same types were used in the PCBUSB too. The ID fields > of the CAN messages (and another data fields int the API) defined as > DWORD which is unsigned long in the PCBUSB headers. This type is > compiled to 64 bit wide integer on 64 bit macOS > , > while in the peakcan_symbols_p.h > > it is defined as a quint32. This could be also workarounded by some ifdefs. > > Thank you for your feedback in advance! > > -- > Best regards, > Miklos Marton > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Kai.Koehne at qt.io Thu Jul 5 10:56:43 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 5 Jul 2018 08:56:43 +0000 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <109198973.Zd6vTh2GyC@tjmaciei-mobl1> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3519150.er6nee5kCn@tjmaciei-mobl1> <2911AACC-F53B-41F2-9033-863A351FB74A@qt.io> <109198973.Zd6vTh2GyC@tjmaciei-mobl1> Message-ID: Hi, I've been creating https://codereview.qt-project.org/#/c/233962/2 to pin down what I assume is consensus so far. This is an update to QUIP-4 (https://quips-qt-io.herokuapp.com/quip-0004.html), which regulates how we handle Third-Party Components in Qt. I also added a paragraph that all newly reported known security vulnerabilities in Third-Party Modules should go through the Qt Project security mailing list. Kai PS: Notes from the session at the Qt Contributor Summit are available at https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: Monday, June 11, 2018 1:18 PM > To: development at qt-project.org > Subject: Re: [Development] QtCS 2018: Third-party and security policy > > On Monday, 11 June 2018 10:56:42 CEST EXT Eike Ziller wrote: > > If we are about to release Qt Creator with LLVM/Clang 6.0, and > > LLVM/Clang > > 6.1 is released, this has good chances to introduce bugs. Aside from > > that, updating the binaries that we ship is an effort, since they are > > profile optimized etc etc. If instead LLVM/Clang 7.0 should be > > released, Qt Creator might not even compile anymore. The probability > > that some functionality is broken increases even more. After we fix > > all these issues (it’s 1-2 weeks later now than the original schedule), a new > version of sqlite is released. > > Good point about chasing a moving target. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Thu Jul 5 12:44:24 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 5 Jul 2018 10:44:24 +0000 Subject: [Development] [Announce] Qt Creator 4.7 RC released Message-ID: We are happy to announce the release of Qt Creator 4.7 RC! http://blog.qt.io/blog/2018/07/05/qt-creator-4-7-rc-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From thiago.macieira at intel.com Thu Jul 5 16:48:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 5 Jul 2018 07:48:09 -0700 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <109198973.Zd6vTh2GyC@tjmaciei-mobl1> Message-ID: <3369426.UDTWG2r0bJ@tjmaciei-mobl1> On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: > PS: Notes from the session at the Qt Contributor Summit are available at > https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security Thanks Kai. Do we have a volunteer to trial out vcpkg and explain to the rest of us how it would work for Qt? Will it be invisible to our users and ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu Jul 5 19:56:38 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 5 Jul 2018 13:56:38 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/27/2018 12:22 PM, Phil Bouchard wrote: > > Also I did my fair amount of contributions to science with: > - the root_ptr memory manager > - the astrophysics theory currently being peer-reviewed by the “Monthly > Notices of the Royal Astronomical Society” Correction: - the astrophysics theory is now peer-reviewed by the "International Conference of Theoretical Physics" (in NY this August) and it was accepted for publication in their proceeding. Regards, -Phil From thiago.macieira at intel.com Thu Jul 5 21:53:14 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 5 Jul 2018 12:53:14 -0700 Subject: [Development] Raising the minimum Core Language to C++14 for Linux/XCB Message-ID: <1741906.Xrd7akKfng@tjmaciei-mobl1> On Mac, we kinda already require that. I'm asking to raise the minimum for the regular Linux builds to C++14. Specifically, I'm asking for the "auto" functions without trailing return type and relaxed constexpr. Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8 elsewhere. That would raise the minimum on Linux to GCC 5, as per: https://gcc.gnu.org/projects/cxx-status.html#cxx14 That's a 3-year-old compiler, four releases out of date, present in the main, binary Linux distros since: Ubuntu 15.10 [2015] Fedora 22 [2015] Debian 9 (Stretch) [2017] openSUSE Leap 15 [2018] Note that this does not apply to QNX or Android, so C++14 features would not be allowed in cross-platform code. But we'd be able to use it in the XCB plugin. [Does QNX build that?] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jul 5 21:54:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 5 Jul 2018 12:54:39 -0700 Subject: [Development] Raising the minimum Android NDK version Message-ID: <4292324.T6dSZakdiv@tjmaciei-mobl1> I've just been told that Android's libc contains a definition that is invalid for Android: the _PATH_MOUNTED definition in points to a file that does not exist on Android systems. Instead of applying a workaround, can we just raise the minimum NDK to one that fixes the issue? Are there still valid reasons for requiring old NDKs? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vindrg at gmail.com Thu Jul 5 22:29:04 2018 From: vindrg at gmail.com (Vincas Dargis) Date: Thu, 5 Jul 2018 23:29:04 +0300 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <4292324.T6dSZakdiv@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> Message-ID: <4311da5a-f120-0e49-6d38-14287773c0e2@gmail.com> On 7/5/18 10:54 PM, Thiago Macieira wrote: > Instead of applying a workaround, can we just raise the minimum NDK to one > that fixes the issue? Are there still valid reasons for requiring old NDKs? I see that there is still work in progress to support Clang, as GCC NDK is being deprecated, if I understand it correctly: https://bugreports.qt.io/browse/QTBUG-67464 From Corey.Pendleton at garmin.com Fri Jul 6 00:50:14 2018 From: Corey.Pendleton at garmin.com (Pendleton, Corey) Date: Thu, 5 Jul 2018 22:50:14 +0000 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <4311da5a-f120-0e49-6d38-14287773c0e2@gmail.com> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <4311da5a-f120-0e49-6d38-14287773c0e2@gmail.com> Message-ID: FWIW: We were able to build Qt 5.9.3 for Android 8.1 using NDK r16b and clang for both 32 and 64-bit platforms. The main hurdle was getting OpenSSL to build, but they are already making preparations as well, so it was not a terrible effort. Note: We build a subset of Qt modules, so I don't know about issues in the full repo. I have also heard from some Qt folks that there may be a plan to update to clang with the latest NDK along with the 5.12 LTS release? Corey -----Original Message----- From: Development [mailto:development-bounces+corey.pendleton=garmin.com at qt-project.org] On Behalf Of Vincas Dargis Sent: Thursday, July 05, 2018 3:29 PM To: Thiago Macieira ; development at qt-project.org Subject: Re: [Development] Raising the minimum Android NDK version On 7/5/18 10:54 PM, Thiago Macieira wrote: > Instead of applying a workaround, can we just raise the minimum NDK to > one that fixes the issue? Are there still valid reasons for requiring old NDKs? I see that there is still work in progress to support Clang, as GCC NDK is being deprecated, if I understand it correctly: https://bugreports.qt.io/browse/QTBUG-67464 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. From Shawn.Rutledge at qt.io Fri Jul 6 10:50:44 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 6 Jul 2018 08:50:44 +0000 Subject: [Development] Dark mode, palettes, styles etc. In-Reply-To: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> Message-ID: <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> > On 4 Jul 2018, at 16:19, Morten Sørvig wrote: > > Hi all, > > macOS 10.14 is now in (public) beta and we've had some time to test Qt on it. > > ... > Dark appearance: In theory, applications should pick up the dark appearance via > the style and palette. In practice, they may not due to incomplete/buggy QPalette > and QMacStyle implementations, or hardcoded colors in Qt or the application. > > The current state of the patches for dev/5.12 is that custom-styled applications > can work well in dark mode, for example Qt Creator with a dark theme. > > The plan is to disable dark mode support by default in Qt, at least until > QMacStyle is fixed. This means that applications will start up using standard > Aqua theme/colors, also when the desktop is configured for dark mode. > > The application has the final call here, and can opt in or out by setting the > NSRequiresAquaSystemAppearance key in the Info.plist file. For example: > > NSRequiresAquaSystemAppearance > > > will indicate that the app _does_ support dark mode, and Qt will get out > of the way and not apply its disable. Setting it to true will insulate the > app against any changes in the Qt default. I would like to see this feature as a cross-platform feature rather than mac-specific. I missed that news about Apple until now, but I had the idea a few years ago anyway that there should be an easy global switch (always within reach, not having to paw through system settings) to toggle quickly between light and dark themes. There was the first time I started up my laptop on a plane while other passengers were trying to sleep, and got some dirty looks because I didn’t have much control over the brightness (the laptop’s backlight level couldn’t be reduced enough, and it took some time to open up the system settings and switch themes, and then I think I had to log out and back in again too. Creator didn’t have themes at all back then.) And there was a consultancy customer a few years ago who planned to have themes with different brightness levels in an embedded application, but AFAIK they still haven’t gotten around to it, maybe because we didn’t make it particularly easy in Qt Quick. And actually I tend to switch themes at least seasonally: if there’s a lot of sun and I’m trying to hack while riding the metro, I can’t see well enough if the theme is too dark, but otherwise I like using a dark theme in darker conditions. So it’s been annoying me for years that most applications can’t easily switch (they tend to make up for lack of system-wide settings by having their own instead), and some desktop environments have inconvenient controls, and/or the theme changes don’t necessarily propagate to all apps at once. But now that Apple is finally doing something, I think the copycats are inevitable, so I fully expect to see news that an identical or better feature is coming soon to KDE and/or Gnome any day now. For now there’s just “redshift", it seems. But IMO having a lot of white space that has gone dingy in the dark is not as nice as having a theme that looks good without having so much white in it. And so far Apple didn’t put the switch in the menubar, but I suppose that’s probably inevitable too: a utility will probably show up in the app store, if there’s an API to make it possible. Anyway, to the extent that widgets and controls are drawn with QPalette colors, switching the palette globally ought to be easy; and we have QEvent::PaletteChange, so applications have already been able to respond quickly to system-wide palette changes for ages, right? But there’s the trend of using image-based styles more, which contributes to the annoyance that you don’t actually have system-wide control over colors and styles. So it just becomes more work for widgets, controls and applications to have both sets of images, in addition to having different resolutions for high-dpi support, whenever they are built that way. The default Fusion widget style still has hard-coded colors, by the way. I wanted to fix it, but ran into resistance about using QSettings for that, and yet no other solution has been forthcoming either. One of the contributing reasons that _we_ use images more is probably because of the perception that a GPU is best used as a texture-flinging device, because it's not so good at drawing vector graphics. (So much so that Shapes are a really recent addition, while Canvas and QtSVG continue to use QPainter to render to a texture.) That’s always been unfortunate from my perspective… _our_ use of today’s gaming-oriented GPUs still hasn't advanced the state of the art in 2D since the 1980’s, unless you use vendor-specific stuff like NV_path_rendering, or if you draw aliased graphics and then apply (expensive) global antialiasing techniques like MSAA. (But I continue to believe it’s possible to do better than that. Especially now that we have Vulkan.) You can write smarter shaders, but then you need a diversity of shaders, and that breaks batching in the scene graph. That’s just wrong IMO. Fixing that somehow would enable us to go back to having styles that use vector graphics and therefore can respond to changes in the palette. But another way is to use a fragment shader to switch specific colors on the fly. I did this with my PDF viewer, to make it possible to read “white papers” in the dark: it inverts black and white, but leaves color images intact. It could at least be a workaround for applications that use too many images. Another easy thing I think we could add to QPalette is the set of (16?) most-common colors. That way, when an application really wants something to be blue, it could use QPalette:Blue, and the theme would be able to control the brightness and the exact shade of blue. (The color of blue that is default on a white xterm is nowhere near the one you want if your terminal is black.) So you could easily "solarize" your whole desktop, if that’s your thing, even while applications retain control over the general hues. Then terminal applications, editors that have syntax highlighting, and such things would be able to use those colors. The settings to define each of those would be global, and the need for e.g. Konsole and Creator to have their own independent sets of themes for text highlighting would go away. (Although, Creator would still need settings to map highlighting classes to QPalette colors: e.g. comments are green and keywords are blue, or whatever.) So they too would respond to global theme changes. There is talk of rearchitecting QStyle in Qt 6. IMO this is a very important feature we should take into account. From jeanmichael.celerier at gmail.com Fri Jul 6 11:47:10 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 6 Jul 2018 11:47:10 +0200 Subject: [Development] Dark mode, palettes, styles etc. In-Reply-To: <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> Message-ID: > Another easy thing I think we could add to QPalette is the set of (16?) most-common colors. That way, when an application really wants something to be blue, it could use QPalette:Blue, and the theme would be able to control the brightness and the exact shade of blue. A good benchmark for this would be to check how it would work with the Base16 theming framework, based on 16 colors : https://github.com/chriskempson/base16 ; they can be checked there : http://chriskempson.com/projects/base16/ There's also Kvantum which is a SVG theme engine for Qt (examples: https://store.kde.org/browse/cat/123/) ; it would be nice to have it integrated to Qt directly maybe ? And then use a GPU-based SVG renderer to only have to do the GPU work once (how far is QtQuick.Shapes from rendering full-fledged SVG ?). Best, Jean-Michaël ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Jul 6, 2018 at 10:50 AM, Shawn Rutledge wrote: > > > On 4 Jul 2018, at 16:19, Morten Sørvig wrote: > > > > Hi all, > > > > macOS 10.14 is now in (public) beta and we've had some time to test Qt > on it. > > > > ... > > Dark appearance: In theory, applications should pick up the dark > appearance via > > the style and palette. In practice, they may not due to incomplete/buggy > QPalette > > and QMacStyle implementations, or hardcoded colors in Qt or the > application. > > > > The current state of the patches for dev/5.12 is that custom-styled > applications > > can work well in dark mode, for example Qt Creator with a dark theme. > > > > The plan is to disable dark mode support by default in Qt, at least until > > QMacStyle is fixed. This means that applications will start up using > standard > > Aqua theme/colors, also when the desktop is configured for dark mode. > > > > The application has the final call here, and can opt in or out by > setting the > > NSRequiresAquaSystemAppearance key in the Info.plist file. For example: > > > > NSRequiresAquaSystemAppearance > > > > > > will indicate that the app _does_ support dark mode, and Qt will get out > > of the way and not apply its disable. Setting it to true will insulate > the > > app against any changes in the Qt default. > > I would like to see this feature as a cross-platform feature rather than > mac-specific. > > I missed that news about Apple until now, but I had the idea a few years > ago anyway that there should be an easy global switch (always within reach, > not having to paw through system settings) to toggle quickly between light > and dark themes. There was the first time I started up my laptop on a > plane while other passengers were trying to sleep, and got some dirty looks > because I didn’t have much control over the brightness (the laptop’s > backlight level couldn’t be reduced enough, and it took some time to open > up the system settings and switch themes, and then I think I had to log out > and back in again too. Creator didn’t have themes at all back then.) And > there was a consultancy customer a few years ago who planned to have themes > with different brightness levels in an embedded application, but AFAIK they > still haven’t gotten around to it, maybe because we didn’t make it > particularly easy in Qt Quick. And actually I tend to switch themes at > least seasonally: if there’s a lot of sun and I’m trying to hack while > riding the metro, I can’t see well enough if the theme is too dark, but > otherwise I like using a dark theme in darker conditions. So it’s been > annoying me for years that most applications can’t easily switch (they tend > to make up for lack of system-wide settings by having their own instead), > and some desktop environments have inconvenient controls, and/or the theme > changes don’t necessarily propagate to all apps at once. > > But now that Apple is finally doing something, I think the copycats are > inevitable, so I fully expect to see news that an identical or better > feature is coming soon to KDE and/or Gnome any day now. For now there’s > just “redshift", it seems. But IMO having a lot of white space that has > gone dingy in the dark is not as nice as having a theme that looks good > without having so much white in it. And so far Apple didn’t put the switch > in the menubar, but I suppose that’s probably inevitable too: a utility > will probably show up in the app store, if there’s an API to make it > possible. > > Anyway, to the extent that widgets and controls are drawn with QPalette > colors, switching the palette globally ought to be easy; and we have > QEvent::PaletteChange, so applications have already been able to respond > quickly to system-wide palette changes for ages, right? But there’s the > trend of using image-based styles more, which contributes to the annoyance > that you don’t actually have system-wide control over colors and styles. > So it just becomes more work for widgets, controls and applications to have > both sets of images, in addition to having different resolutions for > high-dpi support, whenever they are built that way. > > The default Fusion widget style still has hard-coded colors, by the way. > I wanted to fix it, but ran into resistance about using QSettings for that, > and yet no other solution has been forthcoming either. > > One of the contributing reasons that _we_ use images more is probably > because of the perception that a GPU is best used as a texture-flinging > device, because it's not so good at drawing vector graphics. (So much so > that Shapes are a really recent addition, while Canvas and QtSVG continue > to use QPainter to render to a texture.) That’s always been unfortunate > from my perspective… _our_ use of today’s gaming-oriented GPUs still hasn't > advanced the state of the art in 2D since the 1980’s, unless you use > vendor-specific stuff like NV_path_rendering, or if you draw aliased > graphics and then apply (expensive) global antialiasing techniques like > MSAA. (But I continue to believe it’s possible to do better than that. > Especially now that we have Vulkan.) You can write smarter shaders, but > then you need a diversity of shaders, and that breaks batching in the scene > graph. That’s just wrong IMO. Fixing that somehow would enable us to go > back to having styles that use vector graphics and therefore can respond to > changes in the palette. But another way is to use a fragment shader to > switch specific colors on the fly. I did this with my PDF viewer, to make > it possible to read “white papers” in the dark: it inverts black and white, > but leaves color images intact. It could at least be a workaround for > applications that use too many images. > > Another easy thing I think we could add to QPalette is the set of (16?) > most-common colors. That way, when an application really wants something > to be blue, it could use QPalette:Blue, and the theme would be able to > control the brightness and the exact shade of blue. (The color of blue > that is default on a white xterm is nowhere near the one you want if your > terminal is black.) So you could easily "solarize" your whole desktop, if > that’s your thing, even while applications retain control over the general > hues. Then terminal applications, editors that have syntax highlighting, > and such things would be able to use those colors. The settings to define > each of those would be global, and the need for e.g. Konsole and Creator to > have their own independent sets of themes for text highlighting would go > away. (Although, Creator would still need settings to map highlighting > classes to QPalette colors: e.g. comments are green and keywords are blue, > or whatever.) So they too would respond to global theme changes. > > There is talk of rearchitecting QStyle in Qt 6. IMO this is a very > important feature we should take into account. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Fri Jul 6 17:08:28 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 6 Jul 2018 15:08:28 +0000 Subject: [Development] Dark mode, palettes, styles etc. In-Reply-To: References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> Message-ID: <88913EA4-C25C-48B3-A389-61F2BF68ED0B@qt.io> > On 6 Jul 2018, at 11:47, Jean-Michaël Celerier wrote: > > > Another easy thing I think we could add to QPalette is the set of (16?) most-common colors. That way, when an application really wants something to be blue, it could use QPalette:Blue, and the theme would be able to control the brightness and the exact shade of blue. > > A good benchmark for this would be to check how it would work with the Base16 theming framework, based on 16 colors : https://github.com/chriskempson/base16 ; they can be checked there : http://chriskempson.com/projects/base16/ That looks like a similar idea, but each color has a purpose, it’s not just a named color. Some would overlap with existing QPalette colors, and some would be new to us. To me it sounds OK to add those that we don’t have yet. It looks like Chris decided to use yaml files, but we don’t ship a YAML parser in Qt Core, only in Qt Application Manager. But the parsing looks trivial in this case: just need to look for colons and quotes on each line, that’s all. e.g. https://github.com/tilal6991/base16-onedark-scheme/blob/master/onedark.yaml We need to agree on the best way to serialize a QPalette. JSON has been suggested. CBOR ought to be an option now, but you need a tool to edit it. Not that it would be hard to write one. It looks like KDE consensus is that QSettings is fine for color palettes. e.g. for Kvantum Adapta I have /usr/share/Kvantum/Adapta/Adapta.kvconfig and /usr/share/Kvantum/AdaptaNokto/AdaptaNokto.kvconfig; Breeze has /usr/share/color-schemes/Breeze.colors. Those are all INI files, and it looks like Kvantum’s style/themeconfig/ThemeConfig.cpp uses QSettings to read them. There’s a command-line tool to switch themes: https://www.reddit.com/r/kde/comments/8207td/change_the_theming_based_on_the_time/ lookandfeeltool --apply org.kde.breeze.desktop lookandfeeltool --apply org.kde.breezedark.desktop Fine, so it looks possible to write a plasmoid that has a simple dark/light switch. And widget apps all use the same theme. Even QtQuick is OK: system palette colors are updated when I run lookandfeeltool or otherwise change it. So if an app's Controls style uses palette colors, it should be fine. Maybe the cross-platform guarantee then should be that on other desktops like macOS, the palette colors will be changed appropriately when the user switches to dark mode, and the event is sent to the application to ensure that it re-renders. It sounds like that’s what we can expect anyway: >> On 4 Jul 2018, at 16:19, Morten Sørvig wrote: >> Dark appearance: In theory, applications should pick up the dark appearance via >> the style and palette. In practice, they may not due to incomplete/buggy QPalette >> and QMacStyle implementations, or hardcoded colors in Qt or the application. > There's also Kvantum which is a SVG theme engine for Qt (examples: https://store.kde.org/browse/cat/123/) ; it would be nice to have it integrated to Qt directly maybe ? And then use a GPU-based SVG renderer to only have to do the GPU work once (how far is QtQuick.Shapes from rendering full-fledged SVG ?). Do they use QtSVG to render each widget every time it’s painted, or just use it to generate scaled images that are reused as e.g. 9-patches on each widget, or something else? If it only generates a set of images when the resolution or the theme changes, the rendering cost might be low enough anyway. But here https://github.com/tsujan/Kvantum/blob/master/Kvantum/style/rendering.cpp it looks like Style::renderElement() uses QSvgRenderer directly. Maybe I missed some sort of caching there. QtQuick.Shapes can render SVG paths (see the tiger example), but general SVG support is complex. AFAIK we haven’t yet tried to turn Shapes into a general solution… but it seems worth trying to see how far we could get. It would certainly turn out that some features are too hard, but QtSVG already is limited to SVG Tiny to avoid having to implement everything. I think it would be better to use private APIs to render a whole SVG directly to scene-graph nodes, not construct all those QObjects using the public API. (The tiger example instantiates too many objects.) But even then, it might make every frame more expensive to render; but that could be mitigated by turning on layering I suppose, if it becomes a bottleneck. To render scalable icons, there are a couple more tools already BTW: one is to use an icon font like FontAwesome. If you like flat design, it’s fine, because those icons will usually be monochrome… but at least they’re scalable, and antialiased, you benefit from the speed of TrueType rendering, and switching colors is no problem, so that should be a nice solution for “dark mode". But one feature we are missing is the ability to look up a glyph by name. You might look up and use the Unicode code point; the easier way for now though is to use the icon itself as a literal in your QML Text element (because unlike C++ files, we assume QML is always UTF-8). What I would like as an alternative is Glyph { font.family: “FontAwesome" name: “address-book” // to pick something at random color: palette.buttonText } Text layout is expensive, but the Glyph item would be able to bypass that, because it knows all it has to do is insert a single QSGGlyphNode into the scene graph. But that name lookup bit is the hard part. Freetype has FT_Get_Name_Index( FT_Face face, FT_String* glyph_name ) which I think we could use to implement that… but we don’t use Freetype on every platform, so making this work cross-platform requires a bit of research. Thanks to the popularity of emoticons, there can be color fonts now; but out of the three possible standards for that, only one of them does it by allowing you to make colored layers of the same scalable Bezier curves that TrueType normally uses. Another standard allows the font to contain embedded mipmaps, and another allows it to contain embedded SVG images. But what if the colored layers in the first case could use named colors, wouldn’t that be cool? Another alternative is to use PDF for icons. This is not a way of avoiding software rendering, but PDFium is kindof fast in practice. And your PDFs could include vector graphics rather than images. Color even. So you could use a different “page” for each icon… and to make that nice to use, I need to finish up the patches to allow you to choose the page number or frame number in any QML Image. (I was thinking it would work equally well for animated image formats as for multi-page formats like PDF and TIFF.) It’s on my todo list for when Input Handlers are sufficiently “done” that I have time for other things again. But now we’re off topic for “dark mode”… scalable graphics with their own hard-coded colors don’t really help to accomplish that, it’s only when some sort of color palette lookup could be used that it would help. Or switching graphics completely, but you can do that with images too. From jhihn at gmx.com Fri Jul 6 21:15:29 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 6 Jul 2018 21:15:29 +0200 Subject: [Development] Dark mode, palettes, styles etc. In-Reply-To: <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> Message-ID: > Sent: Friday, July 06, 2018 at 4:50 AM > From: "Shawn Rutledge" > To: "development at qt-project.org" > Subject: [Development] Dark mode, palettes, styles etc. > > > > On 4 Jul 2018, at 16:19, Morten Sørvig wrote: > > > > Hi all, > > > > macOS 10.14 is now in (public) beta and we've had some time to test Qt on it. > > > > ... ... > > will indicate that the app _does_ support dark mode, and Qt will get out > > of the way and not apply its disable. Setting it to true will insulate the > > app against any changes in the Qt default. > > I would like to see this feature as a cross-platform feature rather than mac-specific. > ... > There is talk of rearchitecting QStyle in Qt 6. IMO this is a very important feature we should take into account. QStyle should be usable with QtQuick, but without requiring linking of widgets, that is to say there needs to be a QQuickStyle class or something. From scootergrisen at gmail.com Fri Jul 6 23:47:21 2018 From: scootergrisen at gmail.com (scootergrisen) Date: Fri, 6 Jul 2018 23:47:21 +0200 Subject: [Development] Dropping file in Qt Linguist window is not allowed everywhere Message-ID: <685e5ab9-d57c-b436-8fd2-5dec81ba93cb@gmail.com> If i drag a file i want to open into Qt Linguist i would like the window to accept the fil nomatter where i drop i. It seems the drop it only allowed in three panes. Context, string and translation panes. Using: Qt Linguist 5.10.1 Windows 7 From scootergrisen at gmail.com Fri Jul 6 23:51:49 2018 From: scootergrisen at gmail.com (scootergrisen) Date: Fri, 6 Jul 2018 23:51:49 +0200 Subject: [Development] Qt Linguist jumps after translation when list is sorted Message-ID: When i translate a file in Qt Linguist i like to sort the context pane so that all untranslated strings are first. But if i do that and then translate a string and that string is the last in the category instead of just going to the next string when i hit Ctrl+Enter it jump to the very first string. This is annoying before the very first string might be a string i dont want to translate at the moment. Using: Qt Linguist 5.10.1 Windows 7 From apoenitz at t-online.de Fri Jul 6 21:02:06 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 6 Jul 2018 21:02:06 +0200 Subject: [Development] Dropping file in Qt Linguist window is not allowed everywhere In-Reply-To: <685e5ab9-d57c-b436-8fd2-5dec81ba93cb@gmail.com> References: <685e5ab9-d57c-b436-8fd2-5dec81ba93cb@gmail.com> Message-ID: <20180706190206.GA2017@klara.mpi.htwm.de> On Fri, Jul 06, 2018 at 11:47:21PM +0200, scootergrisen wrote: > If i drag a file i want to open into Qt Linguist i would like the window to > accept the fil nomatter where i drop i. > > It seems the drop it only allowed in three panes. Context, string and > translation panes. The best place for such reports is bugreports.qt-project.org. Andre' From fabio.palomba.89 at gmail.com Sat Jul 7 11:33:42 2018 From: fabio.palomba.89 at gmail.com (Fabio Palomba) Date: Sat, 7 Jul 2018 11:33:42 +0200 Subject: [Development] Invitation for a quick interview on the Qt code review process Message-ID: <93520E27-1D12-437A-8E5A-6426C6F1E81F@gmail.com> Dear Qters, We are a team of academic researchers (*) who are trying to understand and improve code review processes and tools. Currently, we are conducting a study to understand the information that developers need to perform a good code review. Since we have analyzed code review data from Qt, it would be great if we could talk with some of you about our findings in a quick (20 minute max) call. In this call, we would ask you about your experience with code review and your view on the results we got from your project’s data. In line with the open source nature of your project, we will make all our data, results, and analysis publicly available. Moreover, if you accept to participate, we will gladly make a donation of 50 euros to your project or a charity of your choice, as a thank you for your time. If you agree to spend 20 minutes on a chat with us, we would need to know it as soon as possible and schedule the chat no later than Tuesday (Jul 10). Our e-mail addresses are also indicated at the bottom of the message. We are also available during the weekend if that suits you best. Can’t wait to hear from you! Best regards, Alberto, Fabio, Luca, Davide (*) Alberto Bacchelli, Professor in Empirical Software Engineering, University of Zurich - bacchelli at ifi.uzh.ch Fabio Palomba, Senior Researcher, University of Zurich - palomba at ifi.uzh.ch Luca Pascarella, PhD student, Delft University of Technology, The Netherlands - L.Pascarella at tudelft.nl Davide Spadini, PhD student, Delft University of Technology, The Netherlands - D.Spadini at tudelft.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceperez1996 at gmail.com Sun Jul 8 17:36:00 2018 From: ceperez1996 at gmail.com (The Crow) Date: Sun, 8 Jul 2018 11:36:00 -0400 Subject: [Development] Build Qt Message-ID: [Sorry my English] Hi. I'm student of Automation Engineering and for the last two years I've been developing my degree and personal projects with Qt. I've using Windows and now I switched to Linux. In Windows I successfully build static version of Qt libs many times. Also, I am starting using QML, but in Windows, statically compiled QML applications shows really bad, graphics are not good, showing a "particle rain" in the entire application. I think that this is not a bug, I'm just missing something about QML while building static qt on Windows. This not happen on Linux. The procedure I use to build Qt in Windows is: 1. Install Qt sources. (last available, 5.11.X right now) 2. Install Python 2.7.X to build QML (last available) 3. Open terminal and execute configure command in src directory: configure -prefix “/somePath/Qt511Static” -static -static-runtime -release -opensource -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -opengl desktop -sql-sqlite -make libs -make tools -nomake examples -nomake tests -skip qtwebengine 4. Build: make -k -jN 5. Install: make -k install 6. Set the static kit in Qt Creator I build text-editor qml example statically. There is a image about what I'm getting. I wrote to the release team about this problem and another about Linux font deployment (poorly documented as well). They tell me that pass -fontconfig and that solved my Linux problem. They tell me that the developer team may can help me with the Windows problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: texteditor.jpg Type: image/jpeg Size: 151218 bytes Desc: not available URL: From thiago.macieira at intel.com Mon Jul 9 02:15:36 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 08 Jul 2018 17:15:36 -0700 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 Message-ID: <4494200.OeiRVixnHO@tjmaciei-mobl1> This is the second time I've run into a compiler bug with that XCode's ancient Clang. Can we please upgrade the XCode installation there to the latest available for macOS 10.11? If that's the latest, can we declare that building Qt on 10.11 is no longer supported for Qt 5.12? I'm not asking about deployment, only building. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Mon Jul 9 11:14:36 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 9 Jul 2018 09:14:36 +0000 Subject: [Development] Dark mode, palettes, styles etc. In-Reply-To: <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io>, <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> Message-ID: Shawn Rutledge (6 July 2018 10:50) wrote > [...] I had the idea a few years ago anyway that there should be an > easy global switch (always within reach, not having to paw through > system settings) to toggle quickly between light and dark themes. [...] > But now that Apple is finally doing something, I think the copycats > are inevitable, so I fully expect to see news that an identical or > better feature is coming soon to KDE and/or Gnome any day now. Who knows, perhaps some more modern apps will begin supporting the X Resource I've been using for nearly 3 decades, *.ReverseVideo: true (albeit some apps, e.g. Rxvt, want it spelt "reverseVideo") to achieve "dark mode" under X. Older X-Windows apps (emacs, various terminals, Xephyr, xpdf) support it fine, newer ones (e.g. web-browsers) not so much. (... and there's nothing wrong with copycats - "nothing is new that is under the sun, except for what we have forgotten" ...) > Another easy thing I think we could add to QPalette is the set of > (16?) most-common colors. That way, when an application really wants > something to be blue, it could use QPalette:Blue, and the theme would > be able to control the brightness and the exact shade of blue. (The > color of blue that is default on a white xterm is nowhere near the one > you want if your terminal is black.) So you could easily "solarize" > your whole desktop, if that’s your thing, even while applications > retain control over the general hues. Then terminal applications, > editors that have syntax highlighting, and such things would be able > to use those colors. The settings to define each of those would be > global, and the need for e.g. Konsole and Creator to have their own > independent sets of themes for text highlighting would go away. I like the idea of this sort of abstraction, giving the user better means to personalise what their eyes spend all day on, but the fiddly details are tricky to get right, balancing between ease of use for the vast majority of apps (that only need a few colours and fonts) while providing enough flexibility for those apps that really do need many. > (Although, Creator would still need settings to map highlighting > classes to QPalette colors: e.g. comments are green and keywords are > blue, or whatever.) So they too would respond to global theme > changes. Indeed. In emacs, the font-lock system's settings, as shown by M-x list-faces-display, run to 168 distinct "faces" (i.e. text styles, for different syntactic uses). Most apps aren't going to want a system that takes the abstraction that far, but those that do really do want it. Eddy. From alexandru.croitor at qt.io Mon Jul 9 11:39:05 2018 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 9 Jul 2018 09:39:05 +0000 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <4494200.OeiRVixnHO@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> Message-ID: <006B91CE-66FA-4EE1-BF2A-3CFF0E012A51@qt.io> I believe it already is the latest. As per http://coin/coin/api/results/qt/qtwebengine/e5e1c69e2008205b2178c940c47c1349d6e41c7b/MacOSOSX_10_11x86_64MacOSOSX_10_11x86_64Clangqtci-osx-10.11-x86_64-3-6a86deDeveloperBuild_Release_QtNamespace_NoPch/e45496f196c102ad5a87327cb11c97f68b4b2baf/build_1531080426/log.txt.gz we are using XCode 8.2, and the last supported version on 10.11 is 8.2.1. I don't think that the patch release will make a big difference though. On 9. Jul 2018, at 02:15, Thiago Macieira > wrote: This is the second time I've run into a compiler bug with that XCode's ancient Clang. Can we please upgrade the XCode installation there to the latest available for macOS 10.11? If that's the latest, can we declare that building Qt on 10.11 is no longer supported for Qt 5.12? I'm not asking about deployment, only building. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Mon Jul 9 16:01:17 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 9 Jul 2018 14:01:17 +0000 (UTC) Subject: [Development] Dark mode, palettes, styles etc. References: <114C46E3-C336-4499-8866-181E6FB352E6@qt.io> <1A06356C-3326-4613-A206-BFA65CD64861@qt.io> Message-ID: On Fri, 06 Jul 2018 08:50:44 +0000, Shawn Rutledge wrote: > But there’s the > trend of using image-based styles more, which contributes to the > annoyance that you don’t actually have system-wide control over colors > and styles. At least for Qt/Quick I'm not sure if this a trend Qt has created by not providing powerful scene graph nodes to the user. F.e. one of the very first thing I did was to implement my own type of renderer for rectangles, so that I can do raised/sunken effects with rounded borders and vertical gradients. ( The frames/boxes examples in qskinny show those nodes - quality will be better once Qt-antialising has been added ). Also because Qt/Quick applications are often in fullscreen mode only proper layouting - like it is state of the art with widgets since decades - is not that common anymore. And again Qt/Quick has a responsibility in this as its layouts are not on the same level - even if having a powerful engine below. > So it just becomes more work for widgets, controls and > applications to have both sets of images, in addition to having > different resolutions for high-dpi support, whenever they are built that > way. I remember that once there was a page in the Qt/docs that recommended using layouts and vector graphic formats. Unfortunately Qt was never good at vector graphic formats - neither for widgets nor Quick. ( Actually this would be a wish for Qt 6 I would have ) FYI our application is completely made of SVGs ( more than 1000 different ) that work with different screen resolutions and color schemes. We are precompiling our SVGs into a painter commands at build time. Then the different colors inside those painter commands are replaced at runtime from the themes ( = skins in our terminology ). As our icons are simple and are made of few colors only, rendering them to textures is fast and we are able to interpolate between the colors for animated theme transitions without losing frames. ( The svgviewer example of qskinny shows it - our real application has this smooth transitions between skins for all controls ). > (So much > so that Shapes are a really recent addition, while Canvas and QtSVG > continue to use QPainter to render to a texture.) In the beginning of our project I compared creating our textures from SVGs using the OpenGL paint engine and the raster paint engine. Beside being buggy ( https://bugreports.qt.io/browse/QTBUG-52672 ) and having a worse quality with antialiasing the surprising result was: the OpenGL engine was slower. Not sure if this is still the case. If yes it might be because of the tesselation being more expensive than the actual rendering - but I havn't looked deeper into this. ( My test was done running over our 1000 SVGs - code can be found here: https://github.com/uwerat/qskinny/blob/master/examples/gbenchmark/ Benchmark.cpp ) > There is talk of rearchitecting QStyle in Qt 6. IMO this is a very > important feature we should take into account. Do you also already have specific plans about what to do with Qt/Quick core in Qt6 ? Uwe From scootergrisen at gmail.com Mon Jul 9 16:21:32 2018 From: scootergrisen at gmail.com (scootergrisen) Date: Mon, 9 Jul 2018 16:21:32 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file Message-ID: I would like it if Qt Linguist would tell how many strings are in the file. Menu View>Statistics only shows words and characters. From thiago.macieira at intel.com Mon Jul 9 16:26:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 09 Jul 2018 07:26:58 -0700 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <006B91CE-66FA-4EE1-BF2A-3CFF0E012A51@qt.io> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <006B91CE-66FA-4EE1-BF2A-3CFF0E012A51@qt.io> Message-ID: <1563397.nl99S7K28f@tjmaciei-mobl1> On Monday, 9 July 2018 02:39:05 PDT Alexandru Croitor wrote: > we are using XCode 8.2, and the last supported version on 10.11 is 8.2.1. I > don't think that the patch release will make a big difference though. Then how about my second request? > > If that's the latest, can we declare that building Qt on 10.11 is no > > longer supported for Qt 5.12? I'm not asking about deployment, only > > building. Can we remove 10.11 from the Qt 5.12 CI? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexandru.croitor at qt.io Mon Jul 9 16:31:27 2018 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Mon, 9 Jul 2018 14:31:27 +0000 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <1563397.nl99S7K28f@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <006B91CE-66FA-4EE1-BF2A-3CFF0E012A51@qt.io> <1563397.nl99S7K28f@tjmaciei-mobl1> Message-ID: I believe that's something for the macOS maintainers to decide. > On 9. Jul 2018, at 16:26, Thiago Macieira wrote: > > On Monday, 9 July 2018 02:39:05 PDT Alexandru Croitor wrote: >> we are using XCode 8.2, and the last supported version on 10.11 is 8.2.1. I >> don't think that the patch release will make a big difference though. > > Then how about my second request? > >>> If that's the latest, can we declare that building Qt on 10.11 is no >>> longer supported for Qt 5.12? I'm not asking about deployment, only >>> building. From jhihn at gmx.com Mon Jul 9 20:31:35 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 9 Jul 2018 20:31:35 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: Message-ID: It's XML, so you can probably write a XSLT :-) > Sent: Monday, July 09, 2018 at 10:21 AM > From: scootergrisen > To: development at qt-project.org > Subject: [Development] Qt Linguist should tell how many strings are in a file > > I would like it if Qt Linguist would tell how many strings are in the file. > Menu View>Statistics only shows words and characters. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From scootergrisen at gmail.com Mon Jul 9 20:32:46 2018 From: scootergrisen at gmail.com (scootergrisen) Date: Mon, 9 Jul 2018 20:32:46 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: Message-ID: <62913f03-31f9-ec78-a43d-3c76d7a930c1@gmail.com> Den 09-07-2018 kl. 20:31 skrev Jason H: > It's XML, so you can probably write a XSLT :-) How would that make Qt Linguist show how many strings the ts file have? From lykurg at gmail.com Tue Jul 10 21:31:30 2018 From: lykurg at gmail.com (Lorenz Haas) Date: Tue, 10 Jul 2018 21:31:30 +0200 Subject: [Development] Timeout for QFuture::waitForFinished() Message-ID: Hi, today I wished QFuture::waitForFinished() had a timeout parameter. After a brief look waitForFinished() uses a QWaitCondition::wait() internally, which already provides an optional timeout parameter. So I wonder if there is any technical/intentional reason why there is no timeout parameter? Follow-up question if a timeout could be added: AFAIK adding an new parameter to waitForFinished() or adding an overload is BiC. Thus would a timeout parameter have to wait for Qt6 or could it be realized for Qt 5 e.g. with a behavior like m_cancelOnWait of QFutureSynchronizer? Thanks Lorenz From aha_1980 at gmx.de Tue Jul 10 21:46:23 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Tue, 10 Jul 2018 21:46:23 +0200 Subject: [Development] Timeout for QFuture::waitForFinished() In-Reply-To: References: Message-ID: <561d246e-031b-aefb-9522-9b72cc811392@gmx.de> Hi Lorenz, I can only reply to the second half of your request. > Follow-up question if a timeout could be added: AFAIK adding an new > parameter to waitForFinished() or adding an overload is BiC. That's only true if you *change* the existing method. Adding a new overload while keeping the existing method *is possible*. So if you have: void QFutureWatcher::waitForFinished(); you can add in Qt 5: void QFutureWatcher::waitForFinished(int timeout); and merge both in Qt 6: void QFutureWatcher::waitForFinished(int timeout = 30000); // or -1 Regards, André From lykurg at gmail.com Tue Jul 10 22:07:37 2018 From: lykurg at gmail.com (Lorenz Haas) Date: Tue, 10 Jul 2018 22:07:37 +0200 Subject: [Development] Timeout for QFuture::waitForFinished() In-Reply-To: <561d246e-031b-aefb-9522-9b72cc811392@gmx.de> References: <561d246e-031b-aefb-9522-9b72cc811392@gmx.de> Message-ID: Hi André, you are right. My statement was not precise enough: Adding a parameter to the existing function would be BiC, adding an overload "void QFutureWatcher::waitForFinished(int timeout);" is BC but would be SiC because it makes function pointers ambiguous - at least I think so. About the latter I am also not sure, if that would be a problem since I am not familiar with the exact promises Qt makes about SC. BR Lorenz 2018-07-10 21:46 GMT+02:00 André Hartmann : > Hi Lorenz, > > I can only reply to the second half of your request. > >> Follow-up question if a timeout could be added: AFAIK adding an new >> parameter to waitForFinished() or adding an overload is BiC. > > > That's only true if you *change* the existing method. Adding a new > overload while keeping the existing method *is possible*. So if you have: > > void QFutureWatcher::waitForFinished(); > > you can add in Qt 5: > > void QFutureWatcher::waitForFinished(int timeout); > > and merge both in Qt 6: > > void QFutureWatcher::waitForFinished(int timeout = 30000); // or -1 > > Regards, > André From giuseppe.dangelo at kdab.com Tue Jul 10 23:22:28 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 10 Jul 2018 23:22:28 +0200 Subject: [Development] Timeout for QFuture::waitForFinished() In-Reply-To: References: <561d246e-031b-aefb-9522-9b72cc811392@gmx.de> Message-ID: Il 10/07/2018 22:07, Lorenz Haas ha scritto: > Hi André, > > you are right. My statement was not precise enough: Adding a parameter > to the existing function would be BiC, adding an overload "void > QFutureWatcher::waitForFinished(int timeout);" is BC but would be SiC > because it makes function pointers ambiguous - at least I think so. > About the latter I am also not sure, if that would be a problem since > I am not familiar with the exact promises Qt makes about SC. See QUIP-6 in the quip repository for the rules. (Long story short, overloads are allowed, unless we're talking about signals, slots or other functions we are encouraging to take addresses of; this is still solvable by the user but is really really frowned upon). HTH, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Tue Jul 10 23:55:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 10 Jul 2018 14:55:58 -0700 Subject: [Development] Timeout for QFuture::waitForFinished() In-Reply-To: References: Message-ID: <31942346.AaOR7V77Pn@tjmaciei-mobl1> On Tuesday, 10 July 2018 12:31:30 PDT Lorenz Haas wrote: > So I wonder if there is any technical/intentional reason why there is > no timeout parameter? There may be. The problem with timed thread waits is that you need to wake up and release state at the same time the signaller is trying to use that content. I'm not saying this is an actual issue here as I don't know the code. But there could be such an issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lykurg at gmail.com Wed Jul 11 06:07:24 2018 From: lykurg at gmail.com (Lorenz Haas) Date: Wed, 11 Jul 2018 06:07:24 +0200 Subject: [Development] Timeout for QFuture::waitForFinished() In-Reply-To: <31942346.AaOR7V77Pn@tjmaciei-mobl1> References: <31942346.AaOR7V77Pn@tjmaciei-mobl1> Message-ID: Thanks for all your input. I'll have a look at QUIP-6 and a closer look at the implementation. 2018-07-10 23:55 GMT+02:00 Thiago Macieira : > On Tuesday, 10 July 2018 12:31:30 PDT Lorenz Haas wrote: >> So I wonder if there is any technical/intentional reason why there is >> no timeout parameter? > > There may be. The problem with timed thread waits is that you need to wake up > and release state at the same time the signaller is trying to use that > content. > > I'm not saying this is an actual issue here as I don't know the code. But > there could be such an issue. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kollix at aon.at Wed Jul 11 10:50:26 2018 From: kollix at aon.at (Martin Koller) Date: Wed, 11 Jul 2018 10:50:26 +0200 Subject: [Development] which branch to use for a fix in 5.9 ? Message-ID: <5460234.ma218HDFtU@lapi.koller> Hi, I want to create a patch for the 5.9 version, however it's not clear for me which branch to use. This guide http://wiki.qt.io/Branch-Guidelines says: "All bugfixes go into the "most frozen" maintained branch which they are relevant for. " So I assume I should use 5.9 and not 5.9.6, right ? What is unclear is also: "release: the current deep-frozen branch. It corresponds with one actual release and consequently has a name like 5.3.1. It is (usually) created from the stable branch when a release is imminent. It is terminated by a release tag, after which the branch is merged and deleted." especially the last part "...after which the branch is merged and deleted." However there are multiple 5.x.y branches. Shouldn't they be no more ? -- 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 From andre.hartmann at iseg-hv.de Wed Jul 11 11:09:05 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Wed, 11 Jul 2018 11:09:05 +0200 Subject: [Development] which branch to use for a fix in 5.9 ? In-Reply-To: <5460234.ma218HDFtU@lapi.koller> References: <5460234.ma218HDFtU@lapi.koller> Message-ID: <03c2cf9a-abfc-b54d-f2d4-87c2db9b86fe@iseg-hv.de> Hi Martin, The branch 5.9 is in cherry-picking mode, so all fixes need to go to 5.11 currently. If they are considered relevant for 5.9, they can be cherry-picked afterwards. Regards, André Am 11.07.2018 um 10:50 schrieb Martin Koller: > Hi, > > I want to create a patch for the 5.9 version, > however it's not clear for me which branch to use. > > This guide http://wiki.qt.io/Branch-Guidelines > says: > "All bugfixes go into the "most frozen" maintained branch which they are relevant for." > > So I assume I should use 5.9 and not 5.9.6, right ? > > What is unclear is also: > > "release: the current deep-frozen branch. It corresponds with one actual release and consequently has a name like 5.3.1. It is (usually) created from the stable branch when a release is imminent. It is terminated by a release tag, after which the branch is merged and deleted." > > especially the last part "...after which the branch is merged and deleted." > However there are multiple 5.x.y branches. Shouldn't they be no more ? > From edward.welbourne at qt.io Wed Jul 11 11:07:40 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 11 Jul 2018 09:07:40 +0000 Subject: [Development] which branch to use for a fix in 5.9 ? In-Reply-To: <5460234.ma218HDFtU@lapi.koller> References: <5460234.ma218HDFtU@lapi.koller> Message-ID: Martin Koller (11 July 2018 10:50) wrote (inter alia): > So I assume I should use 5.9 and not 5.9.6, right ? Yes, except that that's an LTS branch, so it only gets cherry-picks back from other branches (unless you have a strong reason otherwise). Which means you actually need to send it to 5.11 (the current oldest branch accepting new commits) and, once it's integrated, git cherry-pick -x (the -x puts useful things into the commit message) *from the integrated branch* (not from your local commit, that you pushed for review) your change back to 5.9. It's a bit fiddly, but it saves us the need to merge up from LTS branches when the next most recent branch is far enough away that conflicts are apt to be common. > "... It is terminated by a release tag, after which the branch is > merged and deleted." [...] > However there are multiple 5.x.y branches. Shouldn't they be no more ? Apparently we've been neglecting to delete old branches. Thanks for pointing it out - I hope Ossi and/or the release team shall take note and catch up with those deletions. The way you can tell whether a branch is stale is to ask git tag what tags it knows about; you'll see there is a v5.9.6 tag, therefore it's too late to push something to branch 5.9.6. Eddy. From thiago.macieira at intel.com Wed Jul 11 18:21:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 Jul 2018 09:21:17 -0700 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <1563397.nl99S7K28f@tjmaciei-mobl1> Message-ID: <19424976.S6NyGHCNS6@tjmaciei-mobl1> On Monday, 9 July 2018 07:31:27 PDT Alexandru Croitor wrote: > I believe that's something for the macOS maintainers to decide. Thanks. Any opinions? The fix for XCode 8.2 broke XCode 9. Can we PLEASE drop XCode 8.2? Like, right now? I can't integrate the performance improvement until that happens. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Tor.arne.Vestbo at qt.io Thu Jul 12 00:13:00 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 11 Jul 2018 22:13:00 +0000 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <19424976.S6NyGHCNS6@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <1563397.nl99S7K28f@tjmaciei-mobl1> <19424976.S6NyGHCNS6@tjmaciei-mobl1> Message-ID: <8B58F525-F27F-423A-B16B-9CC2D7F33DB2@qt.io> > On 11 Jul 2018, at 18:21, Thiago Macieira wrote: > > On Monday, 9 July 2018 07:31:27 PDT Alexandru Croitor wrote: >> I believe that's something for the macOS maintainers to decide. > > Thanks. Any opinions? > > The fix for XCode 8.2 broke XCode 9. > > Can we PLEASE drop XCode 8.2? Like, right now? I can't integrate the > performance improvement until that happens. I would love to drop any Xcode except the latest, but unfortunately our CI isn’t set up to build once (against latest SDK/Xcode) and then run tests on older macOS versions. Removing Xcode 8.2 effectively removes 10.11 testing. Seeing as we’re not building/testing on 10.13 (the latest macOS release), or 10.14 (the upcoming release), that would leave us with 10.12 as the single build/test target for macOS. Tor Arne > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Jul 12 02:59:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 Jul 2018 17:59:02 -0700 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <8B58F525-F27F-423A-B16B-9CC2D7F33DB2@qt.io> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <19424976.S6NyGHCNS6@tjmaciei-mobl1> <8B58F525-F27F-423A-B16B-9CC2D7F33DB2@qt.io> Message-ID: <26443811.zqH8CKq4gs@tjmaciei-mobl1> On Wednesday, 11 July 2018 15:13:00 PDT Tor Arne Vestbø wrote: > I would love to drop any Xcode except the latest, but unfortunately our CI > isn’t set up to build once (against latest SDK/Xcode) and then run tests on > older macOS versions. Removing Xcode 8.2 effectively removes 10.11 testing. > Seeing as we’re not building/testing on 10.13 (the latest macOS release), > or 10.14 (the upcoming release), that would leave us with 10.12 as the > single build/test target for macOS. Ok, I've found a workaround to the issue meanwhile. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cavendish.qi at gmail.com Thu Jul 12 08:00:50 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 12 Jul 2018 14:00:50 +0800 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <4292324.T6dSZakdiv@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> Message-ID: https://bugreports.qt.io/browse/QTQAINFRA-1681 https://codereview.qt-project.org/#/c/216306/ https://codereview.qt-project.org/#/c/229465/ People are working on that, hope will get update after summer vacations. -- Liang On Fri, 6 Jul 2018 at 03:54, Thiago Macieira wrote: > I've just been told that Android's libc contains a definition that is > invalid > for Android: the _PATH_MOUNTED definition in points to a file > that > does not exist on Android systems. > > Instead of applying a workaround, can we just raise the minimum NDK to one > that fixes the issue? Are there still valid reasons for requiring old NDKs? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavendish.qi at gmail.com Thu Jul 12 08:02:35 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 12 Jul 2018 14:02:35 +0800 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <8B58F525-F27F-423A-B16B-9CC2D7F33DB2@qt.io> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <1563397.nl99S7K28f@tjmaciei-mobl1> <19424976.S6NyGHCNS6@tjmaciei-mobl1> <8B58F525-F27F-423A-B16B-9CC2D7F33DB2@qt.io> Message-ID: For enabling test on 10.13, see https://codereview.qt-project.org/#/c/231978/ and a few other changes from Tony. Hope that will be done soon after summer vacation. -- Liang On Thu, 12 Jul 2018 at 06:13, Tor Arne Vestbø wrote: > > > On 11 Jul 2018, at 18:21, Thiago Macieira > wrote: > > > > On Monday, 9 July 2018 07:31:27 PDT Alexandru Croitor wrote: > >> I believe that's something for the macOS maintainers to decide. > > > > Thanks. Any opinions? > > > > The fix for XCode 8.2 broke XCode 9. > > > > Can we PLEASE drop XCode 8.2? Like, right now? I can't integrate the > > performance improvement until that happens. > > I would love to drop any Xcode except the latest, but unfortunately our CI > isn’t set up to build once (against latest SDK/Xcode) and then run tests on > older macOS versions. Removing Xcode 8.2 effectively removes 10.11 testing. > Seeing as we’re not building/testing on 10.13 (the latest macOS release), > or 10.14 (the upcoming release), that would leave us with 10.12 as the > single build/test target for macOS. > > Tor Arne > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jul 12 08:32:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 Jul 2018 23:32:16 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: References: <4292324.T6dSZakdiv@tjmaciei-mobl1> Message-ID: <3920332.H5f3kNnH99@tjmaciei-mobl1> On Wednesday, 11 July 2018 23:00:50 PDT Liang Qi wrote: > https://bugreports.qt.io/browse/QTQAINFRA-1681 > https://codereview.qt-project.org/#/c/216306/ > https://codereview.qt-project.org/#/c/229465/ > > People are working on that, hope will get update after summer vacations. Thank you. Do I understand that the minimum version will be r16b? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marten.nordheim at qt.io Fri Jul 13 15:59:09 2018 From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=) Date: Fri, 13 Jul 2018 15:59:09 +0200 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <3369426.UDTWG2r0bJ@tjmaciei-mobl1> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <109198973.Zd6vTh2GyC@tjmaciei-mobl1> <3369426.UDTWG2r0bJ@tjmaciei-mobl1> Message-ID: <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> On 05.07.2018 16:48, Thiago Macieira wrote: > On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: >> PS: Notes from the session at the Qt Contributor Summit are available at >> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > > Thanks Kai. > > Do we have a volunteer to trial out vcpkg and explain to the rest of us how it > would work for Qt? Will it be invisible to our users and ourselves? Note how > Linux distros don't have it nor does Homebrew on Mac. > I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ I'm not sure if this is what people had in mind (e.g. installing dependencies during configure), but it works at the moment for what I've tested it for. Mårten From perezmeyer at gmail.com Fri Jul 13 16:49:47 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 13 Jul 2018 11:49:47 -0300 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3369426.UDTWG2r0bJ@tjmaciei-mobl1> <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> Message-ID: <1636354.sHxYH0uEQd@tonks> El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: > On 05.07.2018 16:48, Thiago Macieira wrote: > > On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: > >> PS: Notes from the session at the Qt Contributor Summit are available at > >> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security > > > > Thanks Kai. > > > > Do we have a volunteer to trial out vcpkg and explain to the rest of us > > how it would work for Qt? Will it be invisible to our users and > > ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. > > I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ > > I'm not sure if this is what people had in mind (e.g. installing > dependencies during configure), but it works at the moment for what I've > tested it for. I understand this as: at configure time download 3rdparty code. From a distro's point of view, if the download can be disabled that's a pretty nice thing to have, because it would mean (and please do correct me if I'm wrong) that Qt tarballs will not bundle 3rdparty code. Or will bundle less of it. -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From marten.nordheim at qt.io Fri Jul 13 16:56:44 2018 From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=) Date: Fri, 13 Jul 2018 16:56:44 +0200 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <1636354.sHxYH0uEQd@tonks> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3369426.UDTWG2r0bJ@tjmaciei-mobl1> <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> <1636354.sHxYH0uEQd@tonks> Message-ID: <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: > El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: >> On 05.07.2018 16:48, Thiago Macieira wrote: >>> On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: >>>> PS: Notes from the session at the Qt Contributor Summit are available at >>>> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security >>> >>> Thanks Kai. >>> >>> Do we have a volunteer to trial out vcpkg and explain to the rest of us >>> how it would work for Qt? Will it be invisible to our users and >>> ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. >> >> I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ >> >> I'm not sure if this is what people had in mind (e.g. installing >> dependencies during configure), but it works at the moment for what I've >> tested it for. > > I understand this as: at configure time download 3rdparty code. That's how the current POC works, but it can/likely will change. And then you could use vcpkg to download your dependencies first and just let configure deal with picking up the libraries (for the most part). Mårten From perezmeyer at gmail.com Fri Jul 13 18:43:06 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 13 Jul 2018 13:43:06 -0300 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <1636354.sHxYH0uEQd@tonks> <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> Message-ID: <12458044.o3GbRarCge@tonks> El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: [snip] > > I understand this as: at configure time download 3rdparty code. > > That's how the current POC works, but it can/likely will change. And > then you could use vcpkg to download your dependencies first and just > let configure deal with picking up the libraries (for the most part). Except we can't run vcpkg, that's why I asked if the download/vcpkg use can be disabled. -- A child of five could understand this. Fetch me a child of five. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From marten.nordheim at qt.io Fri Jul 13 19:55:59 2018 From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=) Date: Fri, 13 Jul 2018 19:55:59 +0200 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <12458044.o3GbRarCge@tonks> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <1636354.sHxYH0uEQd@tonks> <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> <12458044.o3GbRarCge@tonks> Message-ID: <3dfc20e0-5e2a-87c2-e9d6-f7aab926bca8@qt.io> On 13.07.2018 18:43, Lisandro Damián Nicanor Pérez Meyer wrote: > El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: > [snip] >>> I understand this as: at configure time download 3rdparty code. >> That's how the current POC works, but it can/likely will change. And >> then you could use vcpkg to download your dependencies first and just >> let configure deal with picking up the libraries (for the most part). > Except we can't run vcpkg, that's why I asked if the download/vcpkg use can be > disabled. Ah, sorry. Yeah, it'll be voluntary to use it Mårten From thiago.macieira at intel.com Fri Jul 13 22:50:36 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 13 Jul 2018 13:50:36 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <3920332.H5f3kNnH99@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <3920332.H5f3kNnH99@tjmaciei-mobl1> Message-ID: <2346606.yrFLj735gp@tjmaciei-mobl1> On Wednesday, 11 July 2018 23:32:16 PDT Thiago Macieira wrote: > On Wednesday, 11 July 2018 23:00:50 PDT Liang Qi wrote: > > https://bugreports.qt.io/browse/QTQAINFRA-1681 > > https://codereview.qt-project.org/#/c/216306/ > > https://codereview.qt-project.org/#/c/229465/ > > > > People are working on that, hope will get update after summer vacations. > > Thank you. Do I understand that the minimum version will be r16b? Will this apply to 5.11? I need a decision on whether I need to work around NDK bugs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Sat Jul 14 02:05:44 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 13 Jul 2018 21:05:44 -0300 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <3dfc20e0-5e2a-87c2-e9d6-f7aab926bca8@qt.io> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <12458044.o3GbRarCge@tonks> <3dfc20e0-5e2a-87c2-e9d6-f7aab926bca8@qt.io> Message-ID: <510540319.Y5RmRSFoFa@tonks> El viernes, 13 de julio de 2018 14:55:59 -03 Mårten Nordheim escribió: > On 13.07.2018 18:43, Lisandro Damián Nicanor Pérez Meyer wrote: > > El viernes, 13 de julio de 2018 11:56:44 -03 Mårten Nordheim escribió: > > [snip] > > > >>> I understand this as: at configure time download 3rdparty code. > >> > >> That's how the current POC works, but it can/likely will change. And > >> then you could use vcpkg to download your dependencies first and just > >> let configure deal with picking up the libraries (for the most part). > > > > Except we can't run vcpkg, that's why I asked if the download/vcpkg use > > can be disabled. > > Ah, sorry. Yeah, it'll be voluntary to use it That sounds just great :-) -- Mi experiencia me dice que lo que la gente quiere y necesita -en Indonesia, en Turquía, en Italia, en los Estados Unidos, en Brasil, en la Argentina o donde sea- es básicamente lo mismo. La gente quiere comida en la mesa, una vivienda básica, un gobierno que funcione, que en las fuerzas de seguridad haya personas confiables, a las que no tengan que tenerles miedo, educación y salud. ¡La gente de todo el mundo quiere lo mismo! Padre Thomas Michel, jesuita, especialista en diálogo interreligioso, en una entrevista de Elisabetta Piqué para La Nación, 27/09/2006. http://www.lanacion.com.ar/844069 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Sat Jul 14 16:23:01 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 14 Jul 2018 07:23:01 -0700 Subject: [Development] Raising the minimum Core Language to C++14 for Linux/XCB In-Reply-To: <1741906.Xrd7akKfng@tjmaciei-mobl1> References: <1741906.Xrd7akKfng@tjmaciei-mobl1> Message-ID: <2654428.nJ2xrYqRKn@tjmaciei-mobl1> On Thursday, 5 July 2018 12:53:14 PDT Thiago Macieira wrote: > On Mac, we kinda already require that. I'm asking to raise the minimum for > the regular Linux builds to C++14. Specifically, I'm asking for the "auto" > functions without trailing return type and relaxed constexpr. > > Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8 > elsewhere. That would raise the minimum on Linux to GCC 5, as per: > https://gcc.gnu.org/projects/cxx-status.html#cxx14 > > That's a 3-year-old compiler, four releases out of date, present in the > main, binary Linux distros since: > Ubuntu 15.10 [2015] > Fedora 22 [2015] > Debian 9 (Stretch) [2017] > openSUSE Leap 15 [2018] > > Note that this does not apply to QNX or Android, so C++14 features would not > be allowed in cross-platform code. > > But we'd be able to use it in the XCB plugin. [Does QNX build that?] There has been no reply on this subject. Shall I assume silence is consent and we can begin using C++14 constructs in the XCB plugin? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Gatis.Paeglis at qt.io Sun Jul 15 12:17:52 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Sun, 15 Jul 2018 10:17:52 +0000 Subject: [Development] Raising the minimum Core Language to C++14 for Linux/XCB In-Reply-To: <2654428.nJ2xrYqRKn@tjmaciei-mobl1> References: <1741906.Xrd7akKfng@tjmaciei-mobl1>, <2654428.nJ2xrYqRKn@tjmaciei-mobl1> Message-ID: > There has been no reply on this subject. Shall I assume silence is consent and > we can begin using C++14 constructs in the XCB plugin? I think I know which patch you are talking about and then my answer is we can't. The code that you are looking at I want to eventually move in some common place (out of XCB) as part of [1]. [1] https://bugreports.qt.io/browse/QTBUG-65503 ________________________________ From: Development on behalf of Thiago Macieira Sent: Saturday, July 14, 2018 4:23:01 PM To: development at qt-project.org Subject: Re: [Development] Raising the minimum Core Language to C++14 for Linux/XCB On Thursday, 5 July 2018 12:53:14 PDT Thiago Macieira wrote: > On Mac, we kinda already require that. I'm asking to raise the minimum for > the regular Linux builds to C++14. Specifically, I'm asking for the "auto" > functions without trailing return type and relaxed constexpr. > > Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8 > elsewhere. That would raise the minimum on Linux to GCC 5, as per: > https://gcc.gnu.org/projects/cxx-status.html#cxx14 > > That's a 3-year-old compiler, four releases out of date, present in the > main, binary Linux distros since: > Ubuntu 15.10 [2015] > Fedora 22 [2015] > Debian 9 (Stretch) [2017] > openSUSE Leap 15 [2018] > > Note that this does not apply to QNX or Android, so C++14 features would not > be allowed in cross-platform code. > > But we'd be able to use it in the XCB plugin. [Does QNX build that?] There has been no reply on this subject. Shall I assume silence is consent and we can begin using C++14 constructs in the XCB plugin? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gatis.Paeglis at qt.io Sun Jul 15 12:57:46 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Sun, 15 Jul 2018 10:57:46 +0000 Subject: [Development] Raising the minimum Core Language to C++14 for Linux/XCB In-Reply-To: References: <1741906.Xrd7akKfng@tjmaciei-mobl1>, <2654428.nJ2xrYqRKn@tjmaciei-mobl1>, Message-ID: > Raising the minimum Core Language to C++14 for Linux/XCB Ok, the title was bit misleading. You want to increase for all regular Linux builds. That would be fine for the task I linked earlier. But according to http://doc.qt.io/qt-5/supported-platforms.html Red Hat Enterprise Linux 6.6 does not have GCC 5. ________________________________ From: Development on behalf of Gatis Paeglis Sent: Sunday, July 15, 2018 12:17:52 PM To: Thiago Macieira; development at qt-project.org Subject: Re: [Development] Raising the minimum Core Language to C++14 for Linux/XCB > There has been no reply on this subject. Shall I assume silence is consent and > we can begin using C++14 constructs in the XCB plugin? I think I know which patch you are talking about and then my answer is we can't. The code that you are looking at I want to eventually move in some common place (out of XCB) as part of [1]. [1] https://bugreports.qt.io/browse/QTBUG-65503 ________________________________ From: Development on behalf of Thiago Macieira Sent: Saturday, July 14, 2018 4:23:01 PM To: development at qt-project.org Subject: Re: [Development] Raising the minimum Core Language to C++14 for Linux/XCB On Thursday, 5 July 2018 12:53:14 PDT Thiago Macieira wrote: > On Mac, we kinda already require that. I'm asking to raise the minimum for > the regular Linux builds to C++14. Specifically, I'm asking for the "auto" > functions without trailing return type and relaxed constexpr. > > Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8 > elsewhere. That would raise the minimum on Linux to GCC 5, as per: > https://gcc.gnu.org/projects/cxx-status.html#cxx14 > > That's a 3-year-old compiler, four releases out of date, present in the > main, binary Linux distros since: > Ubuntu 15.10 [2015] > Fedora 22 [2015] > Debian 9 (Stretch) [2017] > openSUSE Leap 15 [2018] > > Note that this does not apply to QNX or Android, so C++14 features would not > be allowed in cross-platform code. > > But we'd be able to use it in the XCB plugin. [Does QNX build that?] There has been no reply on this subject. Shall I assume silence is consent and we can begin using C++14 constructs in the XCB plugin? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Sun Jul 15 13:06:30 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 15 Jul 2018 13:06:30 +0200 Subject: [Development] Raising the minimum Core Language to C++14 for Linux/XCB In-Reply-To: References: <1741906.Xrd7akKfng@tjmaciei-mobl1> Message-ID: <17215158.l35uskcumH@twilight> On Sonntag, 15. Juli 2018 12:57:46 CEST Gatis Paeglis wrote: > > Raising the minimum Core Language to C++14 for Linux/XCB > > Ok, the title was bit misleading. You want to increase for all regular Linux > builds. > > That would be fine for the task I linked earlier. But > > according to http://doc.qt.io/qt-5/supported-platforms.html Red Hat > Enterprise Linux 6.6 does not have GCC 5. > It does have gcc 4.9 and that works for most C++14 features, though one of the few C++14 features missing, is relaxed constexpr. `Allan From thiago.macieira at intel.com Sun Jul 15 20:39:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 15 Jul 2018 11:39:58 -0700 Subject: [Development] MinGW configuration change on 5.11 branch? Message-ID: <11023919.nYHPs4cGNE@tjmaciei-mobl1> Twice an integration of mine resulted in ..\..\..\..\shared/emulationdetector.h:62:13: warning: 'bool EmulationDetector::isRunningArmOnX86()' defined but not used [-Wunused- function] static bool isRunningArmOnX86() ^ Has something changed? if so, can whoever made the change roll it back or fix this issue, please? see https://testresults.qt.io/logs/qt/qtbase/ f3d49e430bb465e83b562dc90c11ce1f8f82358e/ WindowsWindows_7x86WindowsWindows_7x86Mingw53qtci-windows-7-x86-3- cb31d0DeveloperBuild_Release_OpenGLDynamic/ 2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/test_1531612896/log.txt.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Tor.arne.Vestbo at qt.io Sun Jul 15 21:06:05 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Sun, 15 Jul 2018 19:06:05 +0000 Subject: [Development] MinGW configuration change on 5.11 branch? In-Reply-To: <11023919.nYHPs4cGNE@tjmaciei-mobl1> References: <11023919.nYHPs4cGNE@tjmaciei-mobl1> Message-ID: > On 15 Jul 2018, at 20:39, Thiago Macieira wrote: > > Twice an integration of mine resulted in > > ..\..\..\..\shared/emulationdetector.h:62:13: warning: 'bool > EmulationDetector::isRunningArmOnX86()' defined but not used [-Wunused- > function] > static bool isRunningArmOnX86() > ^ > It’s been like that a while, see e.g. https://codereview.qt-project.org/#/c/222801/ Is it resulting in an error, or is it just the warning you are seeing? Tor Arne > Has something changed? if so, can whoever made the change roll it back or fix > this issue, please? > > see https://testresults.qt.io/logs/qt/qtbase/ > f3d49e430bb465e83b562dc90c11ce1f8f82358e/ > WindowsWindows_7x86WindowsWindows_7x86Mingw53qtci-windows-7-x86-3- > cb31d0DeveloperBuild_Release_OpenGLDynamic/ > 2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/test_1531612896/log.txt.gz > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sun Jul 15 21:45:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 15 Jul 2018 12:45:27 -0700 Subject: [Development] MinGW configuration change on 5.11 branch? In-Reply-To: References: <11023919.nYHPs4cGNE@tjmaciei-mobl1> Message-ID: <510565948.I4XuXLMJZs@tjmaciei-mobl1> On Sunday, 15 July 2018 12:06:05 PDT Tor Arne Vestbø wrote: > https://codereview.qt-project.org/#/c/222801/ > > Is it resulting in an error, or is it just the warning you are seeing? Uh, that's a good point. It's a warning. I guess my error is elsewhere in the log file... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Mon Jul 16 09:08:44 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 16 Jul 2018 10:08:44 +0300 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <2346606.yrFLj735gp@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <3920332.H5f3kNnH99@tjmaciei-mobl1> <2346606.yrFLj735gp@tjmaciei-mobl1> Message-ID: <1820817.PysAIFrBie@dragon> În ziua de vineri, 13 iulie 2018, la 23:50:36 EEST, Thiago Macieira a scris: > On Wednesday, 11 July 2018 23:32:16 PDT Thiago Macieira wrote: > > On Wednesday, 11 July 2018 23:00:50 PDT Liang Qi wrote: > > > https://bugreports.qt.io/browse/QTQAINFRA-1681 > > > https://codereview.qt-project.org/#/c/216306/ > > > https://codereview.qt-project.org/#/c/229465/ > > > > > > People are working on that, hope will get update after summer vacations. > > > > Thank you. Do I understand that the minimum version will be r16b? > > Will this apply to 5.11? I need a decision on whether I need to work around > NDK bugs. The clang support was added and works fine from 5.9. But I think is too late to switch NDK for 5.11. Cheers, BogDan. From edward.welbourne at qt.io Mon Jul 16 13:50:26 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 16 Jul 2018 11:50:26 +0000 Subject: [Development] Coding style: space after comma In-Reply-To: References: Message-ID: I (3 July 2018 16:37) wrote: > [0] https://wiki.qt.io/Qt_Coding_Style > > I propose to follow (under "Whitespace") the list item > > * Surround binary operators with spaces > > with > > * Leave a space after each comma > > Any objections, or improved wordings ? Hearing no objections or suggested improvements, I've made that edit: https://wiki.qt.io/index.php?title=Qt_Coding_Style&type=revision&diff=34222&oldid=31577 Eddy. From thiago.macieira at intel.com Mon Jul 16 17:48:21 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 Jul 2018 08:48:21 -0700 Subject: [Development] Coding style: space after comma In-Reply-To: References: Message-ID: <3592671.rb0xDl7C4R@tjmaciei-mobl1> On Tuesday, 3 July 2018 07:37:25 PDT Edward Welbourne wrote: > Derived:Derived(Type arg, Mode um, Form ent) > > : Base(arg) > > , mem(um) > , ber(ent) > {} There are spaces before these commas, so they don't conform to coding style now. Newlines are whitespace, so even if you flushed the commas to column 1, there would still be spaces. That's also why lines can end in commas: you can't insert a line break there. As for binary operators, since we usually write "a OP b", either of those spaces could be a new line. It's just that our style says we should make the first one contain the line break, not the second. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 16 17:50:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 Jul 2018 08:50:05 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <1820817.PysAIFrBie@dragon> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <2346606.yrFLj735gp@tjmaciei-mobl1> <1820817.PysAIFrBie@dragon> Message-ID: <2365600.H4SCMarA6K@tjmaciei-mobl1> On Monday, 16 July 2018 00:08:44 PDT Bogdan Vatra via Development wrote: > The clang support was added and works fine from 5.9. But I think is too late > to switch NDK for 5.11. I'm not asking to change compilers. I am asking whether we can require fixed NDK headers? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Jul 16 18:29:43 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 16 Jul 2018 19:29:43 +0300 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3369426.UDTWG2r0bJ@tjmaciei-mobl1> <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> <1636354.sHxYH0uEQd@tonks> <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io> Message-ID: <1052651531758583@iva1-77b79d681cd9.qloud-c.yandex.net> 13.07.2018, 17:57, "Mårten Nordheim" : > On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: >>  El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: >>>  On 05.07.2018 16:48, Thiago Macieira wrote: >>>>  On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: >>>>>  PS: Notes from the session at the Qt Contributor Summit are available at >>>>>  https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security >>>> >>>>  Thanks Kai. >>>> >>>>  Do we have a volunteer to trial out vcpkg and explain to the rest of us >>>>  how it would work for Qt? Will it be invisible to our users and >>>>  ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. >>> >>>  I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ >>> >>>  I'm not sure if this is what people had in mind (e.g. installing >>>  dependencies during configure), but it works at the moment for what I've >>>  tested it for. >> >>  I understand this as: at configure time download 3rdparty code. > > That's how the current POC works, but it can/likely will change. And > then you could use vcpkg to download your dependencies first and just > let configure deal with picking up the libraries (for the most part). Is it possible to use it for MinGW? -- Regards, Konstantin From edward.welbourne at qt.io Mon Jul 16 18:41:51 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 16 Jul 2018 16:41:51 +0000 Subject: [Development] Coding style: space after comma In-Reply-To: <3592671.rb0xDl7C4R@tjmaciei-mobl1> References: , <3592671.rb0xDl7C4R@tjmaciei-mobl1> Message-ID: On Tuesday, 3 July 2018 07:37:25 PDT Edward Welbourne wrote: >> Derived:Derived(Type arg, Mode um, Form ent) >> >> : Base(arg) >> >> , mem(um) >> , ber(ent) >> {} Thiago Macieira (16 July 2018 17:48) > There are spaces before these commas, so they don't conform to coding > style now. Newlines are whitespace, so even if you flushed the commas > to column 1, there would still be spaces. That's also why lines can > end in commas: you can't insert a line break there. My amendment doesn't forbid space before a comma; it merely demands space after the comma, Eddy. From Simon.Hausmann at qt.io Mon Jul 16 19:29:01 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 16 Jul 2018 17:29:01 +0000 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <1052651531758583@iva1-77b79d681cd9.qloud-c.yandex.net> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3369426.UDTWG2r0bJ@tjmaciei-mobl1> <724f0a86-b910-461d-40ad-357ed9a48f4d@qt.io> <1636354.sHxYH0uEQd@tonks> <7be7f210-b4dd-b3c2-4ea2-8b3f55065fb2@qt.io>, <1052651531758583@iva1-77b79d681cd9.qloud-c.yandex.net> Message-ID: <15C063BD-3C03-4BC9-9F5D-EF3DF3C59ABC@qt.io> Hi, It’s possible to develop apps with mingw against a vcpkg build. The vcpkg packages themselves cannot be built with mingw yet. I think that is a missing feature. Simon > On 16. Jul 2018, at 18:29, Konstantin Tokarev wrote: > > > > 13.07.2018, 17:57, "Mårten Nordheim" : >>> On 13.07.2018 16:49, Lisandro Damián Nicanor Pérez Meyer wrote: >>> El viernes, 13 de julio de 2018 10:59:09 -03 Mårten Nordheim escribió: >>>> On 05.07.2018 16:48, Thiago Macieira wrote: >>>>> On Thursday, 5 July 2018 01:56:43 PDT Kai Koehne wrote: >>>>>> PS: Notes from the session at the Qt Contributor Summit are available at >>>>>> https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security >>>>> >>>>> Thanks Kai. >>>>> >>>>> Do we have a volunteer to trial out vcpkg and explain to the rest of us >>>>> how it would work for Qt? Will it be invisible to our users and >>>>> ourselves? Note how Linux distros don't have it nor does Homebrew on Mac. >>>> >>>> I implemented a POC here: https://codereview.qt-project.org/#/c/234478/ >>>> >>>> I'm not sure if this is what people had in mind (e.g. installing >>>> dependencies during configure), but it works at the moment for what I've >>>> tested it for. >>> >>> I understand this as: at configure time download 3rdparty code. >> >> That's how the current POC works, but it can/likely will change. And >> then you could use vcpkg to download your dependencies first and just >> let configure deal with picking up the libraries (for the most part). > > Is it possible to use it for MinGW? > > -- > Regards, > Konstantin > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From robert.loehning at qt.io Tue Jul 17 18:08:30 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Tue, 17 Jul 2018 18:08:30 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: Message-ID: Am 09.07.2018 um 16:21 schrieb scootergrisen: > I would like it if Qt Linguist would tell how many strings are in the file. > Menu View>Statistics only shows words and characters. Doesn't it show this in its lower right corner? From scootergrisen at gmail.com Tue Jul 17 19:20:23 2018 From: scootergrisen at gmail.com (scootergrisen) Date: Tue, 17 Jul 2018 19:20:23 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: Message-ID: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Den 17-07-2018 kl. 18:08 skrev Robert Löhning: > Am 09.07.2018 um 16:21 schrieb scootergrisen: >> I would like it if Qt Linguist would tell how many strings are in the >> file. >> Menu View>Statistics only shows words and characters. > > Doesn't it show this in its lower right corner? It seems so. Have never noticed it. Would be good to include in the statistics. Virtaal (other program) have a properties that shows how many words/strings are translated/untranslated/fuzzy and procentages. I think that is nice so know so i have an idea how much work is left. From jhihn at gmx.com Tue Jul 17 22:49:49 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 17 Jul 2018 22:49:49 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: QtLinguist is horrible. It works, but it certainly does not support a modern workflow. Having maintained an app in 14+ languages, it doesn't do anything I actually need it to do. I'd like to have a website (contract translators don't want to install apps) that shows only those phrases needing translation, by the language enabled for that translator. It was unclear what the work to be done by each translator was when using QtLinguist and multiple translators. Because software evolves while translations are being done, you have many in-flight versions needing reconciliation before release. I ended up writing many scripts to do the diffs to create the final file. It shouldn't be that hard. There's also no audit information in the TS file. It also doesn't help that the .ts XML format itself is a little flawed. The closest I got was using some web service that we were able to export from (https://lokalise.co/ ?). Also having a built-in google translate button would be very helpful for the provisional translations. Let me tell you about the time we translated (in a medical treatment app no less) the word "exit" to "door to the morgue" in Chinese. In the end it works, but this could be made a lot better. > Sent: Tuesday, July 17, 2018 at 1:20 PM > From: scootergrisen > To: development at qt-project.org > Subject: Re: [Development] Qt Linguist should tell how many strings are in a file > > Den 17-07-2018 kl. 18:08 skrev Robert Löhning: > > Am 09.07.2018 um 16:21 schrieb scootergrisen: > >> I would like it if Qt Linguist would tell how many strings are in the > >> file. > >> Menu View>Statistics only shows words and characters. > > > > Doesn't it show this in its lower right corner? > > It seems so. > > Have never noticed it. > > Would be good to include in the statistics. > > Virtaal (other program) have a properties that shows how many > words/strings are translated/untranslated/fuzzy and procentages. > > I think that is nice so know so i have an idea how much work is left. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From edward.welbourne at qt.io Wed Jul 18 10:21:25 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 18 Jul 2018 08:21:25 +0000 Subject: [Development] Heads-up: glibc 2.28 will break matching of [a-z], [0-9] and other ranges Message-ID: Hi all, A discussion on the GNU make mailing list brought this to my attention. Apparently glibc 2.28 is going to implement the POSIX spec on ranges, which says A range expression represents the set of collating elements that fall between two elements in the current collation sequence, inclusively. It is expressed as the starting point and the ending point separated by a hyphen (-). Range expressions must not be used in portable applications [...] This turns out to break globs (and other patterns) using ranges; if you want to match lower-case letters, you need to say [[:lower:]], and similarly for [[:digit:]], etc. For example, [a-z] shall now match all the upper-case letters except A and Z, which you probably didn't intend. More background: https://sourceware.org/bugzilla/show_bug.cgi?id=23393 http://pubs.opengroup.org/onlinepubs/7908799/xbd/re.html#tag_007_003_005 I don't know how that may affect us, but my guess is we probably have to change some shell scripts and potentially also some regexes. I've created QTBUG-69518 to track this, Eddy. From Kai.Koehne at qt.io Wed Jul 18 11:20:40 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 18 Jul 2018 09:20:40 +0000 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > [...] > The closest I got was using some web service that we were able to export from > (https://lokalise.co/ ?). Also having a built-in google translate button would be > very helpful for the provisional translations. So did you use localise.co in the end? If so, how did you organize the data Import and export? For Qt Linguist itself: Nobody has been working on it lately. It does what it does, but extending it is not in the current development focus. Anyhow, if anybody fancies spending some time on it, be welcome to do so 😊 However, for more complicated setups I'd expect that people would use other tools, probably using lconvert to convert .ts files back and forth between standard formats like XLIFF. But we haven't been advertising this much. Regards Kai From announce at qt-project.org Wed Jul 18 13:29:48 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 18 Jul 2018 11:29:48 +0000 Subject: [Development] [Announce] Qt Creator 4.7.0 released Message-ID: We are happy to announce the release of Qt Creator 4.7.0! http://blog.qt.io/blog/2018/07/18/qt-creator-4-7-0-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jhihn at gmx.com Wed Jul 18 15:30:14 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 18 Jul 2018 15:30:14 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: It was unfortunately a combination of lokalise.co and my scripts. The owner/opertator/developer of lokalise was very helpful in adjusting his service which apparently supported Qt 3 to Qt4's format. He complained about issues with the XML, which I later also experienced when writing my merge scripts. We used lokalize to get the translations from the translators and all that entails (user management, scope, etc) I would expect that Qt would adopt/focus on GNU gettext/PO files in the future? > Sent: Wednesday, July 18, 2018 at 5:20 AM > From: "Kai Koehne" > To: "Jason H" , scootergrisen > Cc: "development at qt-project.org" > Subject: RE: [Development] Qt Linguist should tell how many strings are in a file > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > [...] > > The closest I got was using some web service that we were able to export from > > (https://lokalise.co/ ?). Also having a built-in google translate button would be > > very helpful for the provisional translations. > > So did you use localise.co in the end? If so, how did you organize the data > Import and export? > > For Qt Linguist itself: Nobody has been working on it lately. It does what it does, > but extending it is not in the current development focus. Anyhow, > if anybody fancies spending some time on it, be welcome to do so 😊 > > However, for more complicated setups I'd expect that people would use > other tools, probably using lconvert to convert .ts files back and forth > between standard formats like XLIFF. But we haven't been advertising > this much. > > Regards > > Kai > > From Kai.Koehne at qt.io Wed Jul 18 15:47:42 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 18 Jul 2018 13:47:42 +0000 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: > -----Original Message----- > [...] > It was unfortunately a combination of lokalise.co and my scripts. The > owner/opertator/developer of lokalise was very helpful in adjusting his service > which apparently supported Qt 3 to Qt4's format. He complained about issues > with the XML, which I later also experienced when writing my merge scripts. > We used lokalize to get the translations from the translators and all that entails > (user management, scope, etc) Would be good to know exactly what the issues are. > I would expect that Qt would adopt/focus on GNU gettext/PO files in the > future? Well, you can use gettext already right now, for your own translations. Anyhow, I doubt that we can change the existing tooling in Qt to gettext without breaking user code. And given our focus on compatibility, I don't see this happen any time soon. Regards Kai From apoenitz at t-online.de Wed Jul 18 10:16:08 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 18 Jul 2018 10:16:08 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: <20180718081608.GA21721@klara.mpi.htwm.de> On Wed, Jul 18, 2018 at 03:30:14PM +0200, Jason H wrote: > It was unfortunately a combination of lokalise.co and my scripts. The > owner/opertator/developer of lokalise was very helpful in adjusting > his service which apparently supported Qt 3 to Qt4's format. He > complained about issues with the XML, which I later also experienced > when writing my merge scripts. We used lokalize to get the > translations from the translators and all that entails (user > management, scope, etc) > > I would expect that Qt would adopt/focus on GNU gettext/PO files in > the future? I would not expect that. The use of Linguist and the Qt translation system in general is completely optional for a Qt application, you can use any other system for your own translations already now.I Apart from that, Qt translations and gettext are not equivalent featurewise, neither is a super nor a subset of the other, so *dropping* the Qt translation system will hurt someone. Andre' From daniel.savi at gaess.ch Thu Jul 19 22:29:48 2018 From: daniel.savi at gaess.ch (Daniel Savi) Date: Thu, 19 Jul 2018 22:29:48 +0200 Subject: [Development] Why are my merged patches not in dev after checkout? Message-ID: Hello everybody. I'm sorry for the probably stupid question again. Two of my patches have been merged in April (to dev I assume). Now, I did a "git checkout dev" and "git rebase origin/dev" on my local machine that didn't have the dev branch on it before. The rebase command told me, that my local branch was up to date. "git branch" shows that I'm on "dev" My expectation was to have my patches included in that branch. But they aren't, the files are still as they have been before my patch was merged. If anyone wants to check, I'm talking about these two patches: Change-Id: Iaa8ec0246aaba004d98c9e8c66609795101519a9 Change-Id: I2d269ef0f842e73af64d48bfef531d5fa3078088 What am I doing wrong? Regards, Daniel Savi From aha_1980 at gmx.de Thu Jul 19 22:43:58 2018 From: aha_1980 at gmx.de (Andre Hartmann) Date: Thu, 19 Jul 2018 20:43:58 +0000 Subject: [Development] Why are my merged patches not in dev after checkout? In-Reply-To: References: Message-ID: <729mcl.pc4s9b.1hge1d0-qmf@gmx.com> Hi Daniel, Am Donnerstag, 19. Juli 2018 schrieb Daniel Savi: > Hello everybody. I'm sorry for the probably stupid question again. Two > of my patches have been merged in April (to dev I assume). Correct, they landed in dev i.e. upcoming 5.12. > Now, I did a > "git checkout dev" and "git rebase origin/dev" on my local machine that > didn't have the dev branch on it before. The rebase command told me, > that my local branch was up to date. "git branch" shows that I'm on "dev" Have you done 'git fetch' before? > My expectation was to have my patches included in that branch. But they > aren't, the files are still as they have been before my patch was merged. > > If anyone wants to check, I'm talking about these two patches: > Change-Id: Iaa8ec0246aaba004d98c9e8c66609795101519a9 > Change-Id: I2d269ef0f842e73af64d48bfef531d5fa3078088 > > What am I doing wrong? > > Regards, > > Daniel Savi Andre _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Von meinem Jolla gesendet From thomaslmiller91 at gmail.com Fri Jul 20 02:02:23 2018 From: thomaslmiller91 at gmail.com (Thomas Miller) Date: Thu, 19 Jul 2018 17:02:23 -0700 Subject: [Development] Support for Windows Arm64 Desktop Target Message-ID: Hi, I’m a dev at Microsoft and recently I’ve been experimenting with building a Qt distribution that targets Arm64 Windows Desktop. I wanted to know if changes to the Qt codebase to support an arm64 Windows desktop app would be accepted into the project and if so, what it would take to add this distribution as an option to the Qt installer? I’ve had some success modifying the 5.10.1 codebase to build a distribution that targets arm64 apps and I was able to build the notepad example on my amd64 dev machine and run it on one of my arm64 devices. Basically, I started with this patch: https://gist.github.com/tycho/3ce679850a03a39d8c174ac05af56214 and then modified the msvc makefile generator so that I could target arm64 desktop cross platform. Like the arm winrt configuration but targeting arm64 desktop instead of arm Windows store. I also modified windeployqt.exe to look at the architecture of the specified binaries instead of just the address width, so we don’t package amd64 dlls alongside arm64 executables. I ported these changes (which I’m sure will require some iterations) to the dev branch and am currently building them. The diff for that is here: https://gist.github.com/thomaslmiller/b97bc7c7905f6e5fdfb93ee71e2a2fc5 in case anyone wants to look at it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maurice.Kalinowski at qt.io Fri Jul 20 07:13:52 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Fri, 20 Jul 2018 05:13:52 +0000 Subject: [Development] Support for Windows Arm64 Desktop Target In-Reply-To: References: Message-ID: Hi Thomas, Thanks for looking into this. In case your patches are ready, we’d be eager to review them following our guidelines at https://wiki.qt.io/Qt_Contribution_Guidelines https://wiki.qt.io/Setting_up_Gerrit Talking about installers, that might be more complicated. For Windows we provide a huge amount of platforms already and simply put, it depends on the usage share of a platform to be part of the installer. For instance there has been discussions on when we can remove MSVC2015 versions to have both x86 and x64 versions in the installer. However, not being available in the installer does not have an impact on the level of support by Qt. BR, Maurice From: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Thomas Miller Sent: Friday, July 20, 2018 2:02 AM To: development at qt-project.org Subject: [Development] Support for Windows Arm64 Desktop Target Hi, I’m a dev at Microsoft and recently I’ve been experimenting with building a Qt distribution that targets Arm64 Windows Desktop. I wanted to know if changes to the Qt codebase to support an arm64 Windows desktop app would be accepted into the project and if so, what it would take to add this distribution as an option to the Qt installer? I’ve had some success modifying the 5.10.1 codebase to build a distribution that targets arm64 apps and I was able to build the notepad example on my amd64 dev machine and run it on one of my arm64 devices. Basically, I started with this patch: https://gist.github.com/tycho/3ce679850a03a39d8c174ac05af56214 and then modified the msvc makefile generator so that I could target arm64 desktop cross platform. Like the arm winrt configuration but targeting arm64 desktop instead of arm Windows store. I also modified windeployqt.exe to look at the architecture of the specified binaries instead of just the address width, so we don’t package amd64 dlls alongside arm64 executables. I ported these changes (which I’m sure will require some iterations) to the dev branch and am currently building them. The diff for that is here: https://gist.github.com/thomaslmiller/b97bc7c7905f6e5fdfb93ee71e2a2fc5 in case anyone wants to look at it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Jul 20 09:34:35 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 20 Jul 2018 07:34:35 +0000 Subject: [Development] Why are my merged patches not in dev after checkout? In-Reply-To: <729mcl.pc4s9b.1hge1d0-qmf@gmx.com> References: , <729mcl.pc4s9b.1hge1d0-qmf@gmx.com> Message-ID: Am Donnerstag, 19. Juli 2018 schrieb Daniel Savi: >> Now, I did a "git checkout dev" and "git rebase origin/dev" on my >> local machine that didn't have the dev branch on it before. The >> rebase command told me, that my local branch was up to date. "git >> branch" shows that I'm on "dev" Andre Hartmann (19 July 2018 22:43) > Have you done 'git fetch' before? Indeed, perhaps this may be of use: https://wiki.qt.io/Git_Introduction#Obtaining_updates Eddy. From thomaslmiller91 at gmail.com Fri Jul 20 20:08:57 2018 From: thomaslmiller91 at gmail.com (Thomas Miller) Date: Fri, 20 Jul 2018 11:08:57 -0700 Subject: [Development] Support for Windows Arm64 Desktop Target In-Reply-To: References: Message-ID: Thanks Maurice. I'll keep working on the changes and put them up for review when they're ready. Quick question though that I haven't seen addressed in the docs: What's the best way to set up a review with changes in multiple submodules? Should I just push changes for 1 submodule at a time? Thanks, Thomas On Thu, Jul 19, 2018 at 10:13 PM, Maurice Kalinowski < Maurice.Kalinowski at qt.io> wrote: > Hi Thomas, > > > > Thanks for looking into this. In case your patches are ready, we’d be > eager to review them following our guidelines at > > https://wiki.qt.io/Qt_Contribution_Guidelines > > https://wiki.qt.io/Setting_up_Gerrit > > > > Talking about installers, that might be more complicated. For Windows we > provide a huge amount of platforms already and simply put, it depends on > the usage share of a platform to be part of the installer. For instance > there has been discussions on when we can remove MSVC2015 versions to have > both x86 and x64 versions in the installer. > > > > However, not being available in the installer does not have an impact on > the level of support by Qt. > > > > BR, > > Maurice > > > > > > *From:* Development [mailto:development-bounces+maurice.kalinowski= > qt.io at qt-project.org] *On Behalf Of *Thomas Miller > *Sent:* Friday, July 20, 2018 2:02 AM > *To:* development at qt-project.org > *Subject:* [Development] Support for Windows Arm64 Desktop Target > > > > Hi, > > I’m a dev at Microsoft and recently I’ve been experimenting with building > a Qt distribution that targets Arm64 Windows Desktop. > > I wanted to know if changes to the Qt codebase to support an arm64 Windows > desktop app would be accepted into the project and if so, what it would > take to add this distribution as an option to the Qt installer? > > I’ve had some success modifying the 5.10.1 codebase to build a > distribution that targets arm64 apps and I was able to build the notepad > example on my amd64 dev machine and run it on one of my arm64 devices. > > Basically, I started with this patch: https://gist.github.com/tycho/ > 3ce679850a03a39d8c174ac05af56214 and then modified the msvc makefile > generator so that I could target arm64 desktop cross platform. Like the arm > winrt configuration but targeting arm64 desktop instead of arm Windows > store. > > I also modified windeployqt.exe to look at the architecture of the > specified binaries instead of just the address width, so we don’t package > amd64 dlls alongside arm64 executables. > > I ported these changes (which I’m sure will require some iterations) to > the dev branch and am currently building them. The diff for that is here: > https://gist.github.com/thomaslmiller/b97bc7c7905f6e5fdfb93ee71e2a2fc5 in > case anyone wants to look at it. > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jul 20 21:19:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Jul 2018 12:19:30 -0700 Subject: [Development] Support for Windows Arm64 Desktop Target In-Reply-To: References: Message-ID: <1877382.XQ4qSbSa2N@tjmaciei-mobl1> On Friday, 20 July 2018 11:08:57 PDT Thomas Miller wrote: > What's the best way to set up a review with changes in multiple submodules? > Should I just push changes for 1 submodule at a time? One submodule at a time. Don't worry about the update to qt5.git, that's done automatically. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jul 21 04:35:48 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Jul 2018 19:35:48 -0700 Subject: [Development] Qt 6 buildsystem support requirements Message-ID: <4853329.uIsbQuBGgb@tjmaciei-mobl1> 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. 1) Ease of obtention a) Must be packaged by all major package managers where Qt 6 is expected to be relevant. That is, it must be available as a package in: - ArchLinux - Debian testing - Gentoo - Fedora current and previous - openSUSE current and previous - Ubuntu LTS released more than 6 months prior - Homebrew (macOS) I'll take care of Clear Linux, but we apply the "two major distros" rule, so I won't be first. It would be nice to have it in vcpkg/nuget/whatever MSVC uses and FreeBSD ports tree too. b) Must be easily compiled from source on a standard system installation. All of its dependencies must come from the system's package manager and there must be no cyclic dependencies. That is, it cannot require itself to build and it must not depend on Qt, either in source form or binary. c) Must not require too-recent version in order to compile Qt. The versions found in (a) must be sufficient to build Qt 6.0 and this must continue throughout Qt 6's lifetime. 2) Track record a) Must be used by roughly a dozen packages in major distros. I'm not saying all of them have to have a dozen, not even that one of them has a dozen. But all of the ones listed above must have at least one and there must be a dozen distinct packages in total. b) At least one package must have been continuously packaged for two years. One for an RPM distro and one for a .deb distro. c) At least one package of comparable complexity to qtbase, packaged by the three of the six Linux distros I listed. I'm looking for: - compiling certain files with different compiler flags - several third-party dependencies, some required, others optional - lots of configure-time options - installing several different types of targets (binaries, libraries, plugins, arch-dependent files, arch-independent files, documentation, translations, etc.) - obeying distro-supplied options (compiler & linker flags, compiler selection [ccache, icecc, clang], debuginfo split, stripping, etc.) 3) Community support a) Thriving community to ask for help to, whenever issues happen. b) One packager for .deb and one for RPM that will vouch for the buildsystem. I don't think I am being unreasonable. I am being strict, though. I'll put my money where my mouth is: as soon as the requirements are met, I will begin using it and contributing to it, finding out where there may be shortcomings and supplying fixes if possible, bug reports if not. But until then, I will pretend it doesn't exist and will ignore the branch that uses it to build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jul 21 05:01:12 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Jul 2018 20:01:12 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <1560257.9vHDIx7idn@tjmaciei-mobl1> On Friday, 20 July 2018 19:35:48 PDT Thiago Macieira wrote: > I'll take care of Clear Linux, but we apply the "two major distros" rule, so > I won't be first. Fedora and openSUSE already package it, so I will add it to Clear Linux. However, I am blocked by https://bugreports.qt.io/browse/QTCREATORBUG-20832. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Sat Jul 21 07:38:10 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Sat, 21 Jul 2018 08:38:10 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <43777450.rx45z2Uc3E@dragon> Hi, În ziua de sâmbătă, 21 iulie 2018, la 05:35:48 EEST, Thiago Macieira a scris: > Hello > > Having spent far too much time trying to figure out why crappy buildsystems [...] > > 1) Ease of obtention > > a) Must be packaged by all major package managers where Qt 6 is expected to > be relevant. That is, it must be available as a package in: > - ArchLinux > - Debian testing > - Gentoo > - Fedora current and previous > - openSUSE current and previous > - Ubuntu LTS released more than 6 months prior > - Homebrew (macOS) [...] > > b) Must be easily compiled from source on a standard system installation. > All of its dependencies must come from the system's package manager and > there must be no cyclic dependencies. That is, it cannot require itself to > build and it must not depend on Qt, either in source form or binary. You really hate QBS don't you ? :) Anyway IMHO is more important to have a clean, nice and easy to use syntax and to be tooling friendly than 1.b. GN[1] is another example of build system which didn't care too much about 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To my huge surprise, they managed to move it into a separate repo and remove all chromium dependencies (yep, a few months ago you had to checkout the entire chromium repo to build it :) ). Cheers, BogDan. [1] https://gn.googlesource.com/gn/ From thiago.macieira at intel.com Sat Jul 21 08:33:29 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Jul 2018 23:33:29 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <43777450.rx45z2Uc3E@dragon> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <4134580.KDsQlyad1F@tjmaciei-mobl1> On Friday, 20 July 2018 22:38:10 PDT Bogdan Vatra via Development wrote: > > b) Must be easily compiled from source on a standard system installation. > > All of its dependencies must come from the system's package manager and > > there must be no cyclic dependencies. That is, it cannot require itself to > > build and it must not depend on Qt, either in source form or binary. > > You really hate QBS don't you ? :) No, I don't. I've never tried it, not even to bother looking at what a source file looks like, so how could I hate it? All I have are requirements and mine are that it should be easy to build and to fix problems. Because there will be problems. I'm too old to spend time learning how to debug a new buildsystem. I have better things to do. I'd just as soon give up and move on to greener pastures than to bash my head against buildsystem problems again. > Anyway IMHO is more important to have a clean, nice and easy to use syntax > and to be tooling friendly than 1.b. Well, I disagree. If you can't compile the build tool, what use is it to have the nicest language? It's inaccessible. Note I didn't say that the tool shouldn't be *part* of qtbase, like qmake is. I just thought that the objective was to eventually do away with that, to avoid having to bootstrap a tool at the moment of configure -- a tool that becomes more complex with each release. The point on requiring Qt source was that one would need to download and extract qtbase, putting it alongside the tool, just so it can be built. Instead of doing that, I suggest copying the files that one needs into the tool's source tree and packaging those for its release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Sat Jul 21 08:40:47 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 21 Jul 2018 08:40:47 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <43777450.rx45z2Uc3E@dragon> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <2927549.GFeDgte00d@twilight> On Samstag, 21. Juli 2018 07:38:10 CEST Bogdan Vatra via Development wrote: > Hi, > > În ziua de sâmbătă, 21 iulie 2018, la 05:35:48 EEST, Thiago Macieira a scris: > > Hello > > > > Having spent far too much time trying to figure out why crappy > > buildsystems > > [...] > > > 1) Ease of obtention > > > > a) Must be packaged by all major package managers where Qt 6 is expected > > to > > > > be relevant. That is, it must be available as a package in: > > - ArchLinux > > - Debian testing > > - Gentoo > > - Fedora current and previous > > - openSUSE current and previous > > - Ubuntu LTS released more than 6 months prior > > - Homebrew (macOS) > > [...] > > > b) Must be easily compiled from source on a standard system installation. > > All of its dependencies must come from the system's package manager and > > there must be no cyclic dependencies. That is, it cannot require itself to > > build and it must not depend on Qt, either in source form or binary. > > You really hate QBS don't you ? :) > > Anyway IMHO is more important to have a clean, nice and easy to use syntax > and to be tooling friendly than 1.b. > > GN[1] is another example of build system which didn't care too much about > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To > my huge surprise, they managed to move it into a separate repo and remove > all chromium dependencies (yep, a few months ago you had to checkout the > entire chromium repo to build it :) ). > Sounds good, but at least for the last year it has also been so unstable that any older version of GN couldn't build a newer Chromium release, and all the build logic was heavily tied to how Chromium does this, and it has a bootstrapper than never worked in any releases ever, so the only way to build GN was to download GN and build it with the blackbox binary. `Allan From bogdan.vatra at kdab.com Sat Jul 21 09:18:40 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Sat, 21 Jul 2018 10:18:40 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2927549.GFeDgte00d@twilight> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> <2927549.GFeDgte00d@twilight> Message-ID: <5303186.gPFkEZL1xS@dragon> Hi, În ziua de sâmbătă, 21 iulie 2018, la 09:40:47 EEST, Allan Sandfeld Jensen a scris: > On Samstag, 21. Juli 2018 07:38:10 CEST Bogdan Vatra via Development wrote: > > Hi, > > > > În ziua de sâmbătă, 21 iulie 2018, la 05:35:48 EEST, Thiago Macieira a > > scris: > > > Hello > > > > > > Having spent far too much time trying to figure out why crappy > > > buildsystems > > > > [...] > > > > > 1) Ease of obtention > > > > > > a) Must be packaged by all major package managers where Qt 6 is expected > > > to > > > > > > be relevant. That is, it must be available as a package in: > > > - ArchLinux > > > - Debian testing > > > - Gentoo > > > - Fedora current and previous > > > - openSUSE current and previous > > > - Ubuntu LTS released more than 6 months prior > > > - Homebrew (macOS) > > > > [...] > > > > > b) Must be easily compiled from source on a standard system > > > installation. > > > All of its dependencies must come from the system's package manager and > > > there must be no cyclic dependencies. That is, it cannot require itself > > > to > > > build and it must not depend on Qt, either in source form or binary. > > > > You really hate QBS don't you ? :) > > > > Anyway IMHO is more important to have a clean, nice and easy to use syntax > > and to be tooling friendly than 1.b. > > > > GN[1] is another example of build system which didn't care too much about > > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To > > my huge surprise, they managed to move it into a separate repo and remove > > all chromium dependencies (yep, a few months ago you had to checkout the > > entire chromium repo to build it :) ). > > Sounds good, but at least for the last year it has also been so unstable > that any older version of GN couldn't build a newer Chromium release, and > all the build logic was heavily tied to how Chromium does this, and it has > a bootstrapper than never worked in any releases ever, so the only way to > build GN was to download GN and build it with the blackbox binary. > Check the new repo, the bootstrap works ok now (if you don't have clang you'll need to apply https://gn-review.googlesource.com/c/gn/+/2340). I'm not trying to sell GN here, because from my experience, Google folks are quite difficult to work with and not very open to changes. What I'm trying to sell here is QBS which I (still) believe is one of the best buildsystems out there and we should not ditch it just because can't be boostraped (easily?). Cheers, BogDan. From vindrg at gmail.com Sat Jul 21 10:06:30 2018 From: vindrg at gmail.com (Vincas) Date: Sat, 21 Jul 2018 11:06:30 +0300 Subject: [Development] How would Android switching to Vulkan would impact Qt for Android? Message-ID: <5f2950d4-3602-675f-057d-08a360c7b871@localhost> Story: https://www.xda-developers.com/google-android-q-vulkan-graphics-render-ui/ I wonder how it could affect QML apps built for Android? From kevin.kofler at chello.at Sat Jul 21 12:28:08 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 21 Jul 2018 12:28:08 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR There is also this classic (more than 9 years old, yet still to the point): https://spot.livejournal.com/308370.html In particular: > * You've written your own build tool for this code [ +100 points of FAIL ] :-) Kevin Kofler From kevin.kofler at chello.at Sat Jul 21 14:42:08 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 21 Jul 2018 14:42:08 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: Bogdan Vatra via Development wrote: > Anyway IMHO is more important to have a clean, nice and easy to use syntax > and to be tooling friendly than 1.b. A custom build system is always a major pain point for distributions. A circular dependency (what Thiago's 1.b forbids) makes it particularly painful. How should we bootstrap new architectures or entirely new distributions if we cannot build Qt due to the circular dependency between Qt and its build tool? This is a showstopper. > GN[1] is another example of build system which didn't care too much about > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To > my huge surprise, they managed to move it into a separate repo and remove > all chromium dependencies (yep, a few months ago you had to checkout the > entire chromium repo to build it :) ). GN (and its predecessor Gyp) is universally hated by distribution packagers for its non-standardness, weirdness, lack of documentation (including third- party documentation such as tutorials, an issue inherent to custom build systems) and lack of flexibility (custom build systems are never as powerful as widely-used general-purpose build systems). QtWebEngine is a particular pain to package because it uses TWO custom build systems (QMake and GN). The Chromium mess is also what prompted Spot to write the list of FAILs [https://spot.livejournal.com/308370.html] I have already linked to elsewhere in this thread. There is a build system that fulfills all of Thiago's points, and it is already widely used in the Qt community: CMake. Kevin Kofler From jeanmichael.celerier at gmail.com Sat Jul 21 14:48:39 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 21 Jul 2018 14:48:39 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: > There is a build system that fulfills all of Thiago's points, and it is already widely used in the Qt community: CMake. +1, I was flabbergasted when the big objection against CMake in Qt 6 boiled down to "it does not supports all the architectures that Qt supports", so instead of contributing them - or hell, even forking CMake for those specific architectures (what are them ? I use cmake for windows, mac, linux, android, ios and the toolchain file allows for a lot of customization), what, create a new build system from scratch that splits the C++ community further ? There would be so much to gain with a better relationship between Qt and CMake. Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler wrote: > Bogdan Vatra via Development wrote: > > Anyway IMHO is more important to have a clean, nice and easy to use > syntax > > and to be tooling friendly than 1.b. > > A custom build system is always a major pain point for distributions. A > circular dependency (what Thiago's 1.b forbids) makes it particularly > painful. How should we bootstrap new architectures or entirely new > distributions if we cannot build Qt due to the circular dependency between > Qt and its build tool? This is a showstopper. > > > GN[1] is another example of build system which didn't care too much about > > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). > To > > my huge surprise, they managed to move it into a separate repo and remove > > all chromium dependencies (yep, a few months ago you had to checkout the > > entire chromium repo to build it :) ). > > GN (and its predecessor Gyp) is universally hated by distribution > packagers > for its non-standardness, weirdness, lack of documentation (including > third- > party documentation such as tutorials, an issue inherent to custom build > systems) and lack of flexibility (custom build systems are never as > powerful > as widely-used general-purpose build systems). > > QtWebEngine is a particular pain to package because it uses TWO custom > build > systems (QMake and GN). > > The Chromium mess is also what prompted Spot to write the list of FAILs > [https://spot.livejournal.com/308370.html] I have already linked to > elsewhere in this thread. > > > There is a build system that fulfills all of Thiago's points, and it is > already widely used in the Qt community: CMake. > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingw.android at gmail.com Sat Jul 21 15:48:04 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sat, 21 Jul 2018 14:48:04 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: As someone who works on a cross platform distribution let me tell you that cmake is plain terrible. How much custom c++ code does it contains for just qt? Loads, absolutely tonnes or rubbish. On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier < jeanmichael.celerier at gmail.com> wrote: > > There is a build system that fulfills all of Thiago's points, and it is > already widely used in the Qt community: CMake. > > +1, I was flabbergasted when the big objection against CMake in Qt 6 > boiled down to "it does not supports all the architectures that Qt > supports", so instead of contributing them - or hell, even forking CMake > for those specific architectures (what are them ? I use cmake for windows, > mac, linux, android, ios and the toolchain file allows for a lot of > customization), what, create a new build system from scratch that splits > the C++ community further ? There would be so much to gain with a better > relationship between Qt and CMake. > > Best, > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler > wrote: > >> Bogdan Vatra via Development wrote: >> > Anyway IMHO is more important to have a clean, nice and easy to use >> syntax >> > and to be tooling friendly than 1.b. >> >> A custom build system is always a major pain point for distributions. A >> circular dependency (what Thiago's 1.b forbids) makes it particularly >> painful. How should we bootstrap new architectures or entirely new >> distributions if we cannot build Qt due to the circular dependency >> between >> Qt and its build tool? This is a showstopper. >> >> > GN[1] is another example of build system which didn't care too much >> about >> > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). >> To >> > my huge surprise, they managed to move it into a separate repo and >> remove >> > all chromium dependencies (yep, a few months ago you had to checkout the >> > entire chromium repo to build it :) ). >> >> GN (and its predecessor Gyp) is universally hated by distribution >> packagers >> for its non-standardness, weirdness, lack of documentation (including >> third- >> party documentation such as tutorials, an issue inherent to custom build >> systems) and lack of flexibility (custom build systems are never as >> powerful >> as widely-used general-purpose build systems). >> >> QtWebEngine is a particular pain to package because it uses TWO custom >> build >> systems (QMake and GN). >> >> The Chromium mess is also what prompted Spot to write the list of FAILs >> [https://spot.livejournal.com/308370.html] I have already linked to >> elsewhere in this thread. >> >> >> There is a build system that fulfills all of Thiago's points, and it is >> already widely used in the Qt community: CMake. >> >> Kevin Kofler >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Sat Jul 21 16:26:18 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 21 Jul 2018 16:26:18 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: > How much custom c++ code does it contains for just qt? which build system which supports automatic calling of moc doesn't have specific code for qt ? ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly wrote: > As someone who works on a cross platform distribution let me tell you that > cmake is plain terrible. How much custom c++ code does it contains for just > qt? Loads, absolutely tonnes or rubbish. > > On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier < > jeanmichael.celerier at gmail.com> wrote: > >> > There is a build system that fulfills all of Thiago's points, and it is >> already widely used in the Qt community: CMake. >> >> +1, I was flabbergasted when the big objection against CMake in Qt 6 >> boiled down to "it does not supports all the architectures that Qt >> supports", so instead of contributing them - or hell, even forking CMake >> for those specific architectures (what are them ? I use cmake for windows, >> mac, linux, android, ios and the toolchain file allows for a lot of >> customization), what, create a new build system from scratch that splits >> the C++ community further ? There would be so much to gain with a better >> relationship between Qt and CMake. >> >> Best, >> ------- >> Jean-Michaël Celerier >> http://www.jcelerier.name >> >> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler >> wrote: >> >>> Bogdan Vatra via Development wrote: >>> > Anyway IMHO is more important to have a clean, nice and easy to use >>> syntax >>> > and to be tooling friendly than 1.b. >>> >>> A custom build system is always a major pain point for distributions. A >>> circular dependency (what Thiago's 1.b forbids) makes it particularly >>> painful. How should we bootstrap new architectures or entirely new >>> distributions if we cannot build Qt due to the circular dependency >>> between >>> Qt and its build tool? This is a showstopper. >>> >>> > GN[1] is another example of build system which didn't care too much >>> about >>> > 1.a,b,c and it still used in quite big projects (e.g. chrome, >>> fuchsia). To >>> > my huge surprise, they managed to move it into a separate repo and >>> remove >>> > all chromium dependencies (yep, a few months ago you had to checkout >>> the >>> > entire chromium repo to build it :) ). >>> >>> GN (and its predecessor Gyp) is universally hated by distribution >>> packagers >>> for its non-standardness, weirdness, lack of documentation (including >>> third- >>> party documentation such as tutorials, an issue inherent to custom build >>> systems) and lack of flexibility (custom build systems are never as >>> powerful >>> as widely-used general-purpose build systems). >>> >>> QtWebEngine is a particular pain to package because it uses TWO custom >>> build >>> systems (QMake and GN). >>> >>> The Chromium mess is also what prompted Spot to write the list of FAILs >>> [https://spot.livejournal.com/308370.html] I have already linked to >>> elsewhere in this thread. >>> >>> >>> There is a build system that fulfills all of Thiago's points, and it is >>> already widely used in the Qt community: CMake. >>> >>> Kevin Kofler >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingw.android at gmail.com Sat Jul 21 16:39:04 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sat, 21 Jul 2018 15:39:04 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: CMake has its own 'language' that was retrofitted after the fact, evolving from a simple definition based system. So why aren't all these special rules written in that 'language' then? 150 odd k of qt c++ hacks is what we get instead. On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier < jeanmichael.celerier at gmail.com> wrote: > > How much custom c++ code does it contains for just qt? > > which build system which supports automatic calling of moc doesn't have > specific code for qt ? > > > > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly > wrote: > >> As someone who works on a cross platform distribution let me tell you >> that cmake is plain terrible. How much custom c++ code does it contains for >> just qt? Loads, absolutely tonnes or rubbish. >> >> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier < >> jeanmichael.celerier at gmail.com> wrote: >> >>> > There is a build system that fulfills all of Thiago's points, and it >>> is >>> already widely used in the Qt community: CMake. >>> >>> +1, I was flabbergasted when the big objection against CMake in Qt 6 >>> boiled down to "it does not supports all the architectures that Qt >>> supports", so instead of contributing them - or hell, even forking CMake >>> for those specific architectures (what are them ? I use cmake for windows, >>> mac, linux, android, ios and the toolchain file allows for a lot of >>> customization), what, create a new build system from scratch that splits >>> the C++ community further ? There would be so much to gain with a better >>> relationship between Qt and CMake. >>> >>> Best, >>> ------- >>> Jean-Michaël Celerier >>> http://www.jcelerier.name >>> >>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler >>> wrote: >>> >>>> Bogdan Vatra via Development wrote: >>>> > Anyway IMHO is more important to have a clean, nice and easy to use >>>> syntax >>>> > and to be tooling friendly than 1.b. >>>> >>>> A custom build system is always a major pain point for distributions. A >>>> circular dependency (what Thiago's 1.b forbids) makes it particularly >>>> painful. How should we bootstrap new architectures or entirely new >>>> distributions if we cannot build Qt due to the circular dependency >>>> between >>>> Qt and its build tool? This is a showstopper. >>>> >>>> > GN[1] is another example of build system which didn't care too much >>>> about >>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome, >>>> fuchsia). To >>>> > my huge surprise, they managed to move it into a separate repo and >>>> remove >>>> > all chromium dependencies (yep, a few months ago you had to checkout >>>> the >>>> > entire chromium repo to build it :) ). >>>> >>>> GN (and its predecessor Gyp) is universally hated by distribution >>>> packagers >>>> for its non-standardness, weirdness, lack of documentation (including >>>> third- >>>> party documentation such as tutorials, an issue inherent to custom >>>> build >>>> systems) and lack of flexibility (custom build systems are never as >>>> powerful >>>> as widely-used general-purpose build systems). >>>> >>>> QtWebEngine is a particular pain to package because it uses TWO custom >>>> build >>>> systems (QMake and GN). >>>> >>>> The Chromium mess is also what prompted Spot to write the list of FAILs >>>> [https://spot.livejournal.com/308370.html] I have already linked to >>>> elsewhere in this thread. >>>> >>>> >>>> There is a build system that fulfills all of Thiago's points, and it is >>>> already widely used in the Qt community: CMake. >>>> >>>> Kevin Kofler >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at weickelt.de Sat Jul 21 16:41:26 2018 From: richard at weickelt.de (Richard Weickelt) Date: Sat, 21 Jul 2018 16:41:26 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <30d16ecc-af42-4a52-48f3-f07a187dbf7b@weickelt.de> >> How much custom c++ code does it contains for just qt? > > which build system which supports automatic calling of moc doesn't have > specific code for qt ? Qbs :-) At least no C++ code. From jeanmichael.celerier at gmail.com Sat Jul 21 17:42:37 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 21 Jul 2018 17:42:37 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp files in the CMake repo which provide the Qt-specific commands : https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt). Besides... why would it matter that they are implemented in C++ instead of cmake-lang ? If anything, CMake's automoc is in my experience much faster to process the whole repo. Richard: so what's this then ? https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f549cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly wrote: > CMake has its own 'language' that was retrofitted after the fact, evolving > from a simple definition based system. > > So why aren't all these special rules written in that 'language' then? 150 > odd k of qt c++ hacks is what we get instead. > > On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier < > jeanmichael.celerier at gmail.com> wrote: > >> > How much custom c++ code does it contains for just qt? >> >> which build system which supports automatic calling of moc doesn't have >> specific code for qt ? >> >> >> >> >> ------- >> Jean-Michaël Celerier >> http://www.jcelerier.name >> >> On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly >> wrote: >> >>> As someone who works on a cross platform distribution let me tell you >>> that cmake is plain terrible. How much custom c++ code does it contains for >>> just qt? Loads, absolutely tonnes or rubbish. >>> >>> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier < >>> jeanmichael.celerier at gmail.com> wrote: >>> >>>> > There is a build system that fulfills all of Thiago's points, and it >>>> is >>>> already widely used in the Qt community: CMake. >>>> >>>> +1, I was flabbergasted when the big objection against CMake in Qt 6 >>>> boiled down to "it does not supports all the architectures that Qt >>>> supports", so instead of contributing them - or hell, even forking CMake >>>> for those specific architectures (what are them ? I use cmake for windows, >>>> mac, linux, android, ios and the toolchain file allows for a lot of >>>> customization), what, create a new build system from scratch that splits >>>> the C++ community further ? There would be so much to gain with a better >>>> relationship between Qt and CMake. >>>> >>>> Best, >>>> ------- >>>> Jean-Michaël Celerier >>>> http://www.jcelerier.name >>>> >>>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler >>>> wrote: >>>> >>>>> Bogdan Vatra via Development wrote: >>>>> > Anyway IMHO is more important to have a clean, nice and easy to use >>>>> syntax >>>>> > and to be tooling friendly than 1.b. >>>>> >>>>> A custom build system is always a major pain point for distributions. >>>>> A >>>>> circular dependency (what Thiago's 1.b forbids) makes it particularly >>>>> painful. How should we bootstrap new architectures or entirely new >>>>> distributions if we cannot build Qt due to the circular dependency >>>>> between >>>>> Qt and its build tool? This is a showstopper. >>>>> >>>>> > GN[1] is another example of build system which didn't care too much >>>>> about >>>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome, >>>>> fuchsia). To >>>>> > my huge surprise, they managed to move it into a separate repo and >>>>> remove >>>>> > all chromium dependencies (yep, a few months ago you had to checkout >>>>> the >>>>> > entire chromium repo to build it :) ). >>>>> >>>>> GN (and its predecessor Gyp) is universally hated by distribution >>>>> packagers >>>>> for its non-standardness, weirdness, lack of documentation (including >>>>> third- >>>>> party documentation such as tutorials, an issue inherent to custom >>>>> build >>>>> systems) and lack of flexibility (custom build systems are never as >>>>> powerful >>>>> as widely-used general-purpose build systems). >>>>> >>>>> QtWebEngine is a particular pain to package because it uses TWO custom >>>>> build >>>>> systems (QMake and GN). >>>>> >>>>> The Chromium mess is also what prompted Spot to write the list of >>>>> FAILs >>>>> [https://spot.livejournal.com/308370.html] I have already linked to >>>>> elsewhere in this thread. >>>>> >>>>> >>>>> There is a build system that fulfills all of Thiago's points, and it >>>>> is >>>>> already widely used in the Qt community: CMake. >>>>> >>>>> Kevin Kofler >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Jul 21 17:55:36 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 21 Jul 2018 08:55:36 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <4005275.cTA5EogLf2@tjmaciei-mobl1> On Friday, 20 July 2018 19:35:48 PDT Thiago Macieira wrote: > c) Must not require too-recent version in order to compile Qt. The versions > found in ( a) must be sufficient to build Qt 6.0 and this must continue > throughout Qt 6's lifetime. Clarification: I don't mean the versions found at 6.0's release are the ones used for 6.18. I meant that throughout 6.x lifetime, we should build with whatever is packaged in distros relevant for each release, not requiring updates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jul 21 17:48:55 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 21 Jul 2018 08:48:55 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <5303186.gPFkEZL1xS@dragon> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <2927549.GFeDgte00d@twilight> <5303186.gPFkEZL1xS@dragon> Message-ID: <1966611.scSLOb6QLs@tjmaciei-mobl1> On Saturday, 21 July 2018 00:18:40 PDT Bogdan Vatra via Development wrote: > I'm not trying to sell GN here, because from my experience, Google folks are > quite difficult to work with and not very open to changes. Yes, they are. My email started with relating problems trying to build TensorFlow. Why do you think it is difficult to build? It uses bazel and Google loves that too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jul 21 18:06:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 21 Jul 2018 09:06:05 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <10084974.sN9IGWFkMe@tjmaciei-mobl1> On Saturday, 21 July 2018 05:42:08 PDT Kevin Kofler wrote: > Bogdan Vatra via Development wrote: > > Anyway IMHO is more important to have a clean, nice and easy to use syntax > > and to be tooling friendly than 1.b. > > A custom build system is always a major pain point for distributions. A > circular dependency (what Thiago's 1.b forbids) makes it particularly > painful. How should we bootstrap new architectures or entirely new > distributions if we cannot build Qt due to the circular dependency between > Qt and its build tool? This is a showstopper. C'mon, this is easy to solve. Just make sure that the build tool can be built with other tools, at least a minimal version to bootstrap itself. Qbs today has a qmake-based build. Qmake can be built with a simple Makefile, one that doesn't even require GNU Make. CMake has a bootstrap mode too. The problem of the Qt dependency can be solved by copying the necessary files. Why are we even discussing (1.b)? That's got a technical solution. I thought that (2) and (3) would be a lot more contentious. Especially (2.c). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Sat Jul 21 18:24:23 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 21 Jul 2018 18:24:23 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <1dae8907-9f45-5dff-3d07-512dab9bddf9@kdab.com> Il 21/07/2018 17:42, Jean-Michaël Celerier ha scritto: > Besides... why would it matter that they are implemented in C++ instead > of cmake-lang ? If anything, CMake's automoc is in my experience much > faster to process the whole repo. Playing devil's advocate, please bear with me: Because it makes people worry that cmake-lang is too limited, and if you need to do certain things (*), you need to resort to patch the tool itself. Which opens other sets of problems, such as: * what are the things that I can do in cmake-lang and the things I can't do? * Does all of this imply having changes landing in CMake itself, or can one have some sort of plugin system so that a project can ship the CMake C++ plugins to build it? * If the former, what happens if my users are running a "slightly older" CMake that doesn't have my patches in it yet? * If the latter, does it mean that CMake offers stable C++ APIs? How complex is it to learn two sets of APIs (cmake-lang and C++)? My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From mingw.android at gmail.com Sat Jul 21 19:07:17 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sat, 21 Jul 2018 18:07:17 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier wrote: > That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp > files in the CMake repo which provide the Qt-specific commands : > https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt). > What is disingenuous, if not blatantly false? Be specific please. git clone https://gitlab.kitware.com/cmake/cmake.git du -csh cmake/Source/cmQt* 8.0K cmake/Source/cmQtAutoGen.cxx 4.0K cmake/Source/cmQtAutoGen.h 52K cmake/Source/cmQtAutoGenInitializer.cxx 4.0K cmake/Source/cmQtAutoGenInitializer.h 24K cmake/Source/cmQtAutoGenerator.cxx 12K cmake/Source/cmQtAutoGenerator.h 64K cmake/Source/cmQtAutoGeneratorMocUic.cxx 12K cmake/Source/cmQtAutoGeneratorMocUic.h 20K cmake/Source/cmQtAutoGeneratorRcc.cxx 4.0K cmake/Source/cmQtAutoGeneratorRcc.h 204K total I stand corrected, there *used* to be 150K of Qt specific C++ code in CMake, but since I last checked it's grown to 204K (or perhaps I counted it less well last time?) And Giuseppe's devil's advocacy does speak to some of my issues with CMake (along with it's lack of proper cross compilation support, it defaulting to looking in *system* folders (which is never what any non-chrooted distro wants). Qbs is far better IMHO. > Besides... why would it matter that they are implemented in C++ instead of > cmake-lang ? If anything, CMake's automoc is in my experience much faster to > process the whole repo. > > Richard: so what's this then ? > https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f549cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp > > > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly > wrote: >> >> CMake has its own 'language' that was retrofitted after the fact, evolving >> from a simple definition based system. >> >> So why aren't all these special rules written in that 'language' then? 150 >> odd k of qt c++ hacks is what we get instead. >> >> On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier >> wrote: >>> >>> > How much custom c++ code does it contains for just qt? >>> >>> which build system which supports automatic calling of moc doesn't have >>> specific code for qt ? >>> >>> >>> >>> >>> ------- >>> Jean-Michaël Celerier >>> http://www.jcelerier.name >>> >>> On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly >>> wrote: >>>> >>>> As someone who works on a cross platform distribution let me tell you >>>> that cmake is plain terrible. How much custom c++ code does it contains for >>>> just qt? Loads, absolutely tonnes or rubbish. >>>> >>>> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier >>>> wrote: >>>>> >>>>> > There is a build system that fulfills all of Thiago's points, and it >>>>> > is >>>>> already widely used in the Qt community: CMake. >>>>> >>>>> +1, I was flabbergasted when the big objection against CMake in Qt 6 >>>>> boiled down to "it does not supports all the architectures that Qt >>>>> supports", so instead of contributing them - or hell, even forking CMake for >>>>> those specific architectures (what are them ? I use cmake for windows, mac, >>>>> linux, android, ios and the toolchain file allows for a lot of >>>>> customization), what, create a new build system from scratch that splits the >>>>> C++ community further ? There would be so much to gain with a better >>>>> relationship between Qt and CMake. >>>>> >>>>> Best, >>>>> ------- >>>>> Jean-Michaël Celerier >>>>> http://www.jcelerier.name >>>>> >>>>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler >>>>> wrote: >>>>>> >>>>>> Bogdan Vatra via Development wrote: >>>>>> > Anyway IMHO is more important to have a clean, nice and easy to use >>>>>> > syntax >>>>>> > and to be tooling friendly than 1.b. >>>>>> >>>>>> A custom build system is always a major pain point for distributions. >>>>>> A >>>>>> circular dependency (what Thiago's 1.b forbids) makes it particularly >>>>>> painful. How should we bootstrap new architectures or entirely new >>>>>> distributions if we cannot build Qt due to the circular dependency >>>>>> between >>>>>> Qt and its build tool? This is a showstopper. >>>>>> >>>>>> > GN[1] is another example of build system which didn't care too much >>>>>> > about >>>>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome, >>>>>> > fuchsia). To >>>>>> > my huge surprise, they managed to move it into a separate repo and >>>>>> > remove >>>>>> > all chromium dependencies (yep, a few months ago you had to checkout >>>>>> > the >>>>>> > entire chromium repo to build it :) ). >>>>>> >>>>>> GN (and its predecessor Gyp) is universally hated by distribution >>>>>> packagers >>>>>> for its non-standardness, weirdness, lack of documentation (including >>>>>> third- >>>>>> party documentation such as tutorials, an issue inherent to custom >>>>>> build >>>>>> systems) and lack of flexibility (custom build systems are never as >>>>>> powerful >>>>>> as widely-used general-purpose build systems). >>>>>> >>>>>> QtWebEngine is a particular pain to package because it uses TWO custom >>>>>> build >>>>>> systems (QMake and GN). >>>>>> >>>>>> The Chromium mess is also what prompted Spot to write the list of >>>>>> FAILs >>>>>> [https://spot.livejournal.com/308370.html] I have already linked to >>>>>> elsewhere in this thread. >>>>>> >>>>>> >>>>>> There is a build system that fulfills all of Thiago's points, and it >>>>>> is >>>>>> already widely used in the Qt community: CMake. >>>>>> >>>>>> Kevin Kofler >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> > From abbapoh at gmail.com Sat Jul 21 19:39:49 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 21 Jul 2018 20:39:49 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> What you wrote reminds me how government officials spent budget money for the new cars in my country. They write specific tender documentation that fits only one car, say Chevrolet Tahoe (for example, "the car that fits 9 people, has leather interior and has the power of 200hp»). The argumentation is the same - here’s the requirements, who cares that the only one overpriced car fits in them. I have several other requirements for the buildsystem. 1. IDE integration. I really need the IDE know the correct CXX flags for each separate file in my project - that is includes, c++ version and so on. Currently i’m using a generated CMake file at my work and the integration with Qt Creator is awful, i’m using IDE just as a simple text editor - syntax highlighting breaks because IDE can’t find some headers (however, goto definition works for them). 2. Support for cross-compilation and deploying Android/iOS. I’ve used a GYP at work for a QML-based app. I spent a whole week porting Qt application for iOS writing those unreadable gyp files. Not sure if CMake will be much easier, AFAIK, neither QBS nor CMake have full support for iOS and Android deployment in Qt Creator (so i can just press «run» and IDE will do everything for me). However, i don’t see big problems in implementing this with QBS (i made several small patches and i can say that the codebase is neat). However, I won’t be the guy who volunteer to do anything in CMake. Yes, CMake has much more users than QBS, however, how many of them will volunteer to work with CMake’s Qt Creator integration? 5 people? 10? We will end with a separate team of Qt guys working on CMake’s integration with Qt and it’s tools. So the question is - is it easier to port QBS to be built without Qt or to use CMake with Qt? I pay my 2 cents for QBS. > 21 июля 2018 г., в 5:35, Thiago Macieira написал(а): > > 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. > > 1) Ease of obtention > > a) Must be packaged by all major package managers where Qt 6 is expected to be > relevant. That is, it must be available as a package in: > - ArchLinux > - Debian testing > - Gentoo > - Fedora current and previous > - openSUSE current and previous > - Ubuntu LTS released more than 6 months prior > - Homebrew (macOS) > > I'll take care of Clear Linux, but we apply the "two major distros" rule, so I > won't be first. It would be nice to have it in vcpkg/nuget/whatever MSVC uses > and FreeBSD ports tree too. > > b) Must be easily compiled from source on a standard system installation. All > of its dependencies must come from the system's package manager and there must > be no cyclic dependencies. That is, it cannot require itself to build and it > must not depend on Qt, either in source form or binary. > > c) Must not require too-recent version in order to compile Qt. The versions > found in (a) must be sufficient to build Qt 6.0 and this must continue > throughout Qt 6's lifetime. > > 2) Track record > > a) Must be used by roughly a dozen packages in major distros. I'm not saying > all of them have to have a dozen, not even that one of them has a dozen. But > all of the ones listed above must have at least one and there must be a dozen > distinct packages in total. > > b) At least one package must have been continuously packaged for two years. > One for an RPM distro and one for a .deb distro. > > c) At least one package of comparable complexity to qtbase, packaged by the > three of the six Linux distros I listed. I'm looking for: > - compiling certain files with different compiler flags > - several third-party dependencies, some required, others optional > - lots of configure-time options > - installing several different types of targets (binaries, libraries, > plugins, arch-dependent files, arch-independent files, documentation, > translations, etc.) > - obeying distro-supplied options (compiler & linker flags, compiler > selection [ccache, icecc, clang], debuginfo split, stripping, etc.) > > 3) Community support > a) Thriving community to ask for help to, whenever issues happen. > b) One packager for .deb and one for RPM that will vouch for the buildsystem. > > > I don't think I am being unreasonable. I am being strict, though. > > I'll put my money where my mouth is: as soon as the requirements are met, I > will begin using it and contributing to it, finding out where there may be > shortcomings and supplying fixes if possible, bug reports if not. > > But until then, I will pretend it doesn't exist and will ignore the branch > that uses it to build. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From perezmeyer at gmail.com Sat Jul 21 20:53:33 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Sat, 21 Jul 2018 15:53:33 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: El vie., 20 de jul. de 2018 23:36, Thiago Macieira < thiago.macieira at intel.com> escribió: > 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. > Agree to all of them, *specially* 1.b. I would also argue that API/ABI should be stable enough. I mean: a new version should not require rewriting the building rules. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sat Jul 21 23:24:26 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 21 Jul 2018 23:24:26 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> Message-ID: Иван Комиссаров wrote: > I have several other requirements for the buildsystem. > 1. IDE integration. I really need the IDE know the correct CXX flags for > each separate file in my project - that is includes, c++ version and so > on. Currently i’m using a generated CMake file at my work and the > integration with Qt Creator is awful, i’m using IDE just as a simple text > editor - syntax highlighting breaks because IDE can’t find some headers > (however, goto definition works for them). https://www.kdevelop.org/ :-) Kevin Kofler From brettg at posteo.net Sun Jul 22 01:13:46 2018 From: brettg at posteo.net (Brett Gilio) Date: Sat, 21 Jul 2018 18:13:46 -0500 Subject: [Development] How would Android switching to Vulkan would impact Qt for Android? In-Reply-To: <5f2950d4-3602-675f-057d-08a360c7b871@localhost> References: <5f2950d4-3602-675f-057d-08a360c7b871@localhost> Message-ID: <874lgsgp1x.fsf@posteo.net> Vincas writes: > https://www.xda-developers.com/google-android-q-vulkan-graphics-render-ui/ > > I wonder how it could affect QML apps built for Android? It probably won't. Qt has pretty extensive integration for Vulkan. -- Brett M. Gilio Free Software Foundation, Member https://parabola.nu | https://emacs.org From nevion at gmail.com Sun Jul 22 01:52:44 2018 From: nevion at gmail.com (Jason Newton) Date: Sat, 21 Jul 2018 16:52:44 -0700 Subject: [Development] Qt 6 buildsystem support requirements Message-ID: I think this is an incredibly important issue! Sorry if this creates a new thread, I'm hopping on the ML and I don't have any previous mails to reply-to. 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 and here's a few words why. But first, let me direct to a ticket I filed last year on the subject of Qt creator support of bazel: https://bugreports.qt.io/browse/QTCREATORBUG-19085 - I really wish it was something more trivial to integrate. There are too many options right now and seeming none of them are clear winners across the board, though several have shiny features that as a former cmake purist, made me wish I had some of those things. I'd most be interested in meson if I chose to have a limited scope and cmake wins out on "most" libraries supported, which seems to have taken 5-7 years in my own experience for that shift to happen - meaning an official or community based FindLibrary script being available. Cmake has verbosity and limitations though so while it works, and is much better than a make based solution, when it comes to jumping out 95% builtin coverage, particularly where it tends to go more programming language/composition it has problems. I'd support cmake library users, but I wouldn't put the lion share of my effort in it. Meson has deterministic builds and a clean language but I can get that with bazel too - I essentially look at both of these projects as a very common set of features, but bazel features and capabilities keep growing where as I'm not sure where meson will go. Both meson and bazel suffer from few out of the box, batteries included modules for software libraries, leaving users to scrape github (like cmake in its earlier years of mass adoption) - this is a problem that will go away one way or another in time, and an official repo or library with mass collection of them as well as upstream project support for more non-trivial libraries (qt is one of these!) would go miles. Why the qt project may be interested in this in short is: -Probably the most unbounded future of any existing build system, development is quite active with a growing feature set - this is not a simple community effort but fused (although mainly driven by google) and I think that's why you can count on this remaining true and ahead of the pack. -Time tested, running in production environments offering the lowest barrier of entry to "get going" for bazel based projects being built by users, even for non-programmer types. As usual YMMV but I can start a non-software person on a bazel project in a matter of minutes and have a large project functioning on a machine - stories exist like this from google and the like. -Short, python based syntax but much less complicated files than something like scons, while still allowing real programming when needed. -Fast and scaling bazel uses a long lived server technique that hangs around and lower restart times and combined with solid dependency analysis and a built in watching for file-system activity (e.g. inotify) ensures smart rebuilding as well as incremental builds - even as part of the test runner, which has access to this information such that only what might have changed is tested. Large projects like qt build incredibly fast and efficiently - through a variety of strategies bazel takes. Local build caches, external cache servers - can greatly speed up CI based testing (meaning developers wait less) and are integrated in a vastly superior way in contrast to say distcc. The amount of time that useful work is being performed is greater than I've observed in large cmake projects, even using ninja (assuming ninja would work across projects that size, due to frequent make sensitivities) -Ability to build external libraries from source or pull in binary libraries - the former offering alot of power that comes with custom flags and controlled dependencies for users developing products, and the later for distribution like software - the choice is always there and low barrier of entry. One can fuse approaches where it makes sense. -Cross-platform builds work, esoteric stuff does too - docker, android and specialized compilers - not hard to hook in other toolchains (easier/less error prone than cmake) -Cross language under a single build system - python, sh, c/c++, go, obj-c - all have first class support and can "see" eachother in terms of dependency tracking/targets. I have built alot of software against bazel - hdf5, boost, and common simple libraries like tif/png/jpeg, zlib to list a prominent few and it's taken those projects like a champ - generally being smooth sailing. Could it have done better or easier? Yes hdf5 for instance is trickier than most due to autoconf based configuration - I hope things will keep getting easier with it (bazel). That happens one project at a time, but mega projects like qt can be instrumental in making that happen - both solving the problems unique to qt on bazel (changing things that needed to be changed) as well as providing the interface/build rules to correctly use qt6 (official sdk, system installs etc) - both being amplifiers of usage. Cross-platform prebuilt binaries are available from here: https://github.com/bazelbuild/bazel/releases - it can be done fairly stand alone from distribution (by design) though - it's not too hard to package as a deb, rpm, or tar, even if you don't use the facilitated methods of doing that. -Jason From jhihn at gmx.com Sun Jul 22 02:45:36 2018 From: jhihn at gmx.com (Jason H) Date: Sun, 22 Jul 2018 02:45:36 +0200 Subject: [Development] Qt Linguist should tell how many strings are in a file In-Reply-To: References: <184149a8-80a6-28f1-9a78-e5903a27574a@gmail.com> Message-ID: I'll see what I can dig up, but it's a low priority and I don't have access to that repo anymore. > Sent: Wednesday, July 18, 2018 at 9:47 AM > From: "Kai Koehne" > To: "Jason H" > Cc: scootergrisen , "development at qt-project.org" > Subject: RE: RE: [Development] Qt Linguist should tell how many strings are in a file > > > -----Original Message----- > > [...] > > It was unfortunately a combination of lokalise.co and my scripts. The > > owner/opertator/developer of lokalise was very helpful in adjusting his service > > which apparently supported Qt 3 to Qt4's format. He complained about issues > > with the XML, which I later also experienced when writing my merge scripts. > > We used lokalize to get the translations from the translators and all that entails > > (user management, scope, etc) > > Would be good to know exactly what the issues are. > > > I would expect that Qt would adopt/focus on GNU gettext/PO files in the > > future? > > Well, you can use gettext already right now, for your own translations. > > Anyhow, I doubt that we can change the existing tooling in Qt to gettext without breaking user code. And given our focus on compatibility, I don't see this happen any time soon. > > Regards > > Kai > > From thiago.macieira at intel.com Sat Jul 21 22:04:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 21 Jul 2018 13:04:10 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> Message-ID: <2168912.jvzcIB7NHm@tjmaciei-mobl1> On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote: > 1. IDE integration. I really need the IDE know the correct CXX flags for > each separate file in my project - that is includes, c++ version and so on. > Currently i’m using a generated CMake file at my work and the integration > with Qt Creator is awful, i’m using IDE just as a simple text editor - > syntax highlighting breaks because IDE can’t find some headers (however, > goto definition works for them). That's already more than what we have for qmake, so I wouldn't put this as a requirement. It's a nice-to-have. The point is that the tool has to be at least in feature parity with qmake and that includes cross-compilation and IDE support. > Yes, CMake has much more users than QBS, however, how many of them will > volunteer to work with CMake’s Qt Creator integration? 5 people? 10? 5 people would be more than what we currently have for either qmake or qbs today, so seems ok. > So the question is - is it easier to port QBS to be built without Qt or to > use CMake with Qt? Again, solving the build is easy. Please look into the requirements at (2). THAT is a lot harder. And all I'm asking is for experience. I don't want Qt to be the guinea pig. More to the point: I will not be part of the experimentation. Give me a mature tool. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 22 04:05:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 21 Jul 2018 19:05:16 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <1807400.DTfmLMTjGk@tjmaciei-mobl1> On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote: > -Ability to build external libraries from source or pull in binary > libraries This is not a feature. It's a misfeature. It's EXACTLY the reason our seniormost engineers spent three days trying to upgrade TensorFlow in Clear Linux. That's not your junior guy who only knows how to run "npn install". We're talking about people who had been building stuff on Linux years before you'd ever heard about Linux. Anyway, you'll see in my original email that I did not name any buildsytem. I only set forth a set of requirements that any buildsystem worth its salt should be able to meet. We're more than two years away from switching to a new buildsystem, so even if a new one sprung up tomorrow, it would have enough time to meet the (2.b) requirement of one package packaged continuously for 2 years. So maybe bazel has a shot. Or ninja. Or scons. Who knows. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Sun Jul 22 06:57:18 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Sun, 22 Jul 2018 07:57:18 +0300 Subject: [Development] How would Android switching to Vulkan would impact Qt for Android? In-Reply-To: <5f2950d4-3602-675f-057d-08a360c7b871@localhost> References: <5f2950d4-3602-675f-057d-08a360c7b871@localhost> Message-ID: <8151922.NMSAaKUQzB@dragon> Hi, În ziua de sâmbătă, 21 iulie 2018, la 11:06:30 EEST, Vincas a scris: > Story: > > https://www.xda-developers.com/google-android-q-vulkan-graphics-render-ui/ > > I wonder how it could affect QML apps built for Android? It doesn't mean that OpenGL support will be removed, so there should be no problem for OpenGL apps. Cheers, BogDan. From tobias.hunger at gmail.com Sun Jul 22 10:57:59 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Jul 2018 10:57:59 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: Hi Thiago, On Sat, Jul 21, 2018, 04:36 Thiago Macieira wrote: > [...] I'd like to add the following > extra requirements to the buildsystem we choose to use. This is in > addition to > the functionality requirements. > > [...] > 1) Ease of obtention 2) Track record > > 3) Community support > All these are very reasonable to ask for. I personally would like to add the following point for consideration: 4) Toolable A) works with IDE(s) -- preferably more than one B) Should be easy to hook in static and dynamic code analyzer tools Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Sun Jul 22 11:11:44 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Jul 2018 11:11:44 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <43777450.rx45z2Uc3E@dragon> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development < development at qt-project.org> wrote: > You really hate QBS don't you ? :) Do you have so few arguments for qbs that you need to appeal to emotions? :) Anyway IMHO is more important to have a clean, nice and easy to use syntax > and > to be tooling friendly than 1.b. > Sure you can write toolable build files with qbs, but there is nothing stopping you writing an unparsable JS mess either. For QML we needed to define a toolable subset of the language with the UI files to have any chance at tooling it. For the qbs dialect of QML that has not been done yet. So I do not consider qbs to be toolable at this point. Best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Sun Jul 22 11:18:06 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Jul 2018 11:18:06 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier < jeanmichael.celerier at gmail.com> wrote: > +1, I was flabbergasted when the big objection against CMake in Qt 6 > boiled down to "it does not supports all the architectures that Qt > supports", > IIRC the bid showstopper was that CMake does not support building host tools and the target libraries in one go. That requirement was dropped since then in our side. Best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Sun Jul 22 11:20:04 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 22 Jul 2018 21:20:04 +1200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1807400.DTfmLMTjGk@tjmaciei-mobl1> References: <1807400.DTfmLMTjGk@tjmaciei-mobl1> Message-ID: On 22 July 2018 at 14:05, Thiago Macieira wrote: > On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote: >> -Ability to build external libraries from source or pull in binary >> libraries > > This is not a feature. It's a misfeature. > > It's EXACTLY the reason our seniormost engineers spent three days trying to > upgrade TensorFlow in Clear Linux. That's not your junior guy who only knows > how to run "npn install". We're talking about people who had been building > stuff on Linux years before you'd ever heard about Linux. Clear Linux, hum? Are they re-inventing the wheel? And the hammer, the nail, and the saw, what have you... "Kata Container with Clear Linux"? What an obscure technology, and what does it has to do with the Qt project and build system in general? So because Intel re-invents the wheel the Qt project shouldn't use this or that? Honestly, I fail to follow you here. Chris From chgans at gmail.com Sun Jul 22 11:39:57 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 22 Jul 2018 21:39:57 +1200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: On 22 July 2018 at 00:42, Kevin Kofler wrote: > Bogdan Vatra via Development wrote: >> Anyway IMHO is more important to have a clean, nice and easy to use syntax >> and to be tooling friendly than 1.b. > > A custom build system is always a major pain point for distributions. A > circular dependency (what Thiago's 1.b forbids) makes it particularly > painful. How should we bootstrap new architectures or entirely new > distributions if we cannot build Qt due to the circular dependency between > Qt and its build tool? This is a showstopper. How do you build gcc on Debian? Which compiler do you use? How do you build the afore mentioned compiler in the first place? Bootstrapping is a natural process in SW dev, and is and has always been a long meander. Implementation details don't matter. AFAIK, Debian cannot even be cross-compiled (Debian ports have never been build this way).... CMake has a special bootstrapping mode, QMake has one, and any other build tools (can) have their own, this includes Qbs, and many other.. IMHO, this self-contained, circular dependency discussion is moot. As mentioned by Thiago himself, this is a non-problem, it can be easily solved for most build system that are on the table. Can we stop for a moment about self/circular dependency and bootstrapping? Let's move on more serious topics. Chris From mingw.android at gmail.com Sun Jul 22 11:49:29 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sun, 22 Jul 2018 10:49:29 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <1807400.DTfmLMTjGk@tjmaciei-mobl1> Message-ID: On Sun, Jul 22, 2018, 10:20 AM Christian Gagneraud wrote: > On 22 July 2018 at 14:05, Thiago Macieira > wrote: > > On Saturday, 21 July 2018 16:52:44 PDT Jason Newton wrote: > >> -Ability to build external libraries from source or pull in binary > >> libraries > > > > This is not a feature. It's a misfeature. > > > > It's EXACTLY the reason our seniormost engineers spent three days trying > to > > upgrade TensorFlow in Clear Linux. That's not your junior guy who only > knows > > how to run "npn install". We're talking about people who had been > building > > stuff on Linux years before you'd ever heard about Linux. > > Clear Linux, hum? Are they re-inventing the wheel? And the hammer, the > nail, and the saw, what have you... > On the Anaconda Distribution we expend significant ongoing engineer time battling bazel too. We all detest it. > "Kata Container with Clear Linux"? What an obscure technology, and > what does it has to do with the Qt project and build system in > general? > So because Intel re-invents the wheel the Qt project shouldn't use > this or that? Honestly, I fail to follow you here. > > Chris > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Sun Jul 22 12:08:17 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sun, 22 Jul 2018 12:08:17 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: My bad, I thought that you were counting in Kloc of code, not in kilobytes. That's in my opinion a weird metric for measuring code since indenting with, say, 4 spaces instead of 1 tab would certainly end up giving wild differences. cloc cmake/Source/cmQt* ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 5 371 500 4362 C/C++ Header 5 126 173 740 ------------------------------------------------------------------------------- SUM: 10 497 673 5102 ------------------------------------------------------------------------------- I don't know for you, but 5kloc of modern C++ seems to be a fairly small price to pay to parse all my .cpp automatically for moc macros (no need to specify headers unlike qmake!), parallel execution of multiple moc /uic / rcc instances ( https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOGEN_PARALLEL.html), direct support for multiple files with the same name (e.g. having two files with Q_OBJECT named Settings.h in different folders won't cause a problem with cmake, unlike qmake which puts everything in the root build folder by default and will happilly overwrite a moc_Settings.cpp with another), etc ( https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOMOC.html). > Playing devil's advocate, please bear with me: > Because it makes people worry that cmake-lang is too limited, and if you need to do certain things (*), you need to resort to patch the tool itself. But, which build system commonly used with Qt doesn't behave like this ? qmake is cpp + qmake-lang, qbs is cpp + QML. AFAIK meson, waf, scons do not support automatic moc'ing. At some point, some code has to be injected in the build tool if you want to add automatic global behaviour - and I'd take automatic global behaviour everyday over doing stuff like this: http://mesonbuild.com/Qt5-module.html or https://scons.org/doc/2.0.1/HTML/scons-user/a8524.html ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Jul 21, 2018 at 7:07 PM, Ray Donnelly wrote: > On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier > wrote: > > That's fairly disingenuous, if not blatantly false. There are, like, 6 > .cpp > > files in the CMake repo which provide the Qt-specific commands : > > https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt). > > > > What is disingenuous, if not blatantly false? Be specific please. > > git clone https://gitlab.kitware.com/cmake/cmake.git > > du -csh cmake/Source/cmQt* > 8.0K cmake/Source/cmQtAutoGen.cxx > 4.0K cmake/Source/cmQtAutoGen.h > 52K cmake/Source/cmQtAutoGenInitializer.cxx > 4.0K cmake/Source/cmQtAutoGenInitializer.h > 24K cmake/Source/cmQtAutoGenerator.cxx > 12K cmake/Source/cmQtAutoGenerator.h > 64K cmake/Source/cmQtAutoGeneratorMocUic.cxx > 12K cmake/Source/cmQtAutoGeneratorMocUic.h > 20K cmake/Source/cmQtAutoGeneratorRcc.cxx > 4.0K cmake/Source/cmQtAutoGeneratorRcc.h > 204K total > > I stand corrected, there *used* to be 150K of Qt specific C++ code in > CMake, but since I last checked it's grown to 204K (or perhaps I > counted it less well last time?) > > And Giuseppe's devil's advocacy does speak to some of my issues with > CMake (along with it's lack of proper cross compilation support, it > defaulting to looking in *system* folders (which is never what any > non-chrooted distro wants). > > Qbs is far better IMHO. > > > Besides... why would it matter that they are implemented in C++ instead > of > > cmake-lang ? If anything, CMake's automoc is in my experience much > faster to > > process the whole repo. > > > > Richard: so what's this then ? > > https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f54 > 9cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp > > > > > > > > ------- > > Jean-Michaël Celerier > > http://www.jcelerier.name > > > > On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly > > wrote: > >> > >> CMake has its own 'language' that was retrofitted after the fact, > evolving > >> from a simple definition based system. > >> > >> So why aren't all these special rules written in that 'language' then? > 150 > >> odd k of qt c++ hacks is what we get instead. > >> > >> On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier > >> wrote: > >>> > >>> > How much custom c++ code does it contains for just qt? > >>> > >>> which build system which supports automatic calling of moc doesn't have > >>> specific code for qt ? > >>> > >>> > >>> > >>> > >>> ------- > >>> Jean-Michaël Celerier > >>> http://www.jcelerier.name > >>> > >>> On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly > > >>> wrote: > >>>> > >>>> As someone who works on a cross platform distribution let me tell you > >>>> that cmake is plain terrible. How much custom c++ code does it > contains for > >>>> just qt? Loads, absolutely tonnes or rubbish. > >>>> > >>>> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier > >>>> wrote: > >>>>> > >>>>> > There is a build system that fulfills all of Thiago's points, and > it > >>>>> > is > >>>>> already widely used in the Qt community: CMake. > >>>>> > >>>>> +1, I was flabbergasted when the big objection against CMake in Qt 6 > >>>>> boiled down to "it does not supports all the architectures that Qt > >>>>> supports", so instead of contributing them - or hell, even forking > CMake for > >>>>> those specific architectures (what are them ? I use cmake for > windows, mac, > >>>>> linux, android, ios and the toolchain file allows for a lot of > >>>>> customization), what, create a new build system from scratch that > splits the > >>>>> C++ community further ? There would be so much to gain with a better > >>>>> relationship between Qt and CMake. > >>>>> > >>>>> Best, > >>>>> ------- > >>>>> Jean-Michaël Celerier > >>>>> http://www.jcelerier.name > >>>>> > >>>>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler < > kevin.kofler at chello.at> > >>>>> wrote: > >>>>>> > >>>>>> Bogdan Vatra via Development wrote: > >>>>>> > Anyway IMHO is more important to have a clean, nice and easy to > use > >>>>>> > syntax > >>>>>> > and to be tooling friendly than 1.b. > >>>>>> > >>>>>> A custom build system is always a major pain point for > distributions. > >>>>>> A > >>>>>> circular dependency (what Thiago's 1.b forbids) makes it > particularly > >>>>>> painful. How should we bootstrap new architectures or entirely new > >>>>>> distributions if we cannot build Qt due to the circular dependency > >>>>>> between > >>>>>> Qt and its build tool? This is a showstopper. > >>>>>> > >>>>>> > GN[1] is another example of build system which didn't care too > much > >>>>>> > about > >>>>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome, > >>>>>> > fuchsia). To > >>>>>> > my huge surprise, they managed to move it into a separate repo and > >>>>>> > remove > >>>>>> > all chromium dependencies (yep, a few months ago you had to > checkout > >>>>>> > the > >>>>>> > entire chromium repo to build it :) ). > >>>>>> > >>>>>> GN (and its predecessor Gyp) is universally hated by distribution > >>>>>> packagers > >>>>>> for its non-standardness, weirdness, lack of documentation > (including > >>>>>> third- > >>>>>> party documentation such as tutorials, an issue inherent to custom > >>>>>> build > >>>>>> systems) and lack of flexibility (custom build systems are never as > >>>>>> powerful > >>>>>> as widely-used general-purpose build systems). > >>>>>> > >>>>>> QtWebEngine is a particular pain to package because it uses TWO > custom > >>>>>> build > >>>>>> systems (QMake and GN). > >>>>>> > >>>>>> The Chromium mess is also what prompted Spot to write the list of > >>>>>> FAILs > >>>>>> [https://spot.livejournal.com/308370.html] I have already linked to > >>>>>> elsewhere in this thread. > >>>>>> > >>>>>> > >>>>>> There is a build system that fulfills all of Thiago's points, and it > >>>>>> is > >>>>>> already widely used in the Qt community: CMake. > >>>>>> > >>>>>> Kevin Kofler > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Development mailing list > >>>>>> Development at qt-project.org > >>>>>> http://lists.qt-project.org/mailman/listinfo/development > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Development mailing list > >>>>> Development at qt-project.org > >>>>> http://lists.qt-project.org/mailman/listinfo/development > >>> > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sun Jul 22 12:11:17 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 22 Jul 2018 12:11:17 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: Message-ID: Jason Newton wrote: > My conclusion for the build system with the brightest future is bazel Looking at this, this build system depends on Python AND Java! They ship binaries with everything bundled, but that is a huge bloat (and it also does not help GNU/Linux distributions, which will want to use the system versions of the languages). I think a build system should have minimal dependencies, and ideally be written in C++ as Qt itself is. If you require more stuff to build the build system than to build Qt, something is clearly wrong. > -Time tested, running in production environments Bazel is still fairly new and adoption is low, especially in the Free Software world. It is being mostly adopted by "hip" projects rather than the well-known Free Software projects. In particular, it is not widely used in the Qt community. Compare: https://github.com/bazelbuild/bazel/wiki/Bazel-Users vs.: https://cmake.org/ ("Notable Applications Using CMake" section). There is also little to no documentation on packaging Bazel-using software for GNU/Linux distributions. E.g., the Fedora wiki does not contain a single reference to Bazel. (The only 2 results I get with a full-text search are about a person with that surname.) > -Ability to build external libraries from source or pull in binary > libraries - the former offering alot of power that comes with custom > flags and controlled dependencies for users developing products, and > the later for distribution like software - the choice is always there > and low barrier of entry. One can fuse approaches where it makes > sense. GNU/Linux distributions actually want to link against the system libraries, not pull in binaries (nor library sources) into the package. Kevin Kofler From kevin.kofler at chello.at Sun Jul 22 12:31:42 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 22 Jul 2018 12:31:42 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: Message-ID: I wrote: > Bazel is still fairly new and adoption is low, especially in the Free > Software world. PS: In addition, https://bazel.build/ itself describes Bazel as "Beta". In particular, "Bazel is not yet covered by a deprecation policy, may be subject to backward-incompatible changes, and is missing some features." I do not think relying on a beta build system that may change incompatibly at any time is a good idea. Kevin Kofler From abbapoh at gmail.com Sun Jul 22 12:57:37 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sun, 22 Jul 2018 13:57:37 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2168912.jvzcIB7NHm@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> <2168912.jvzcIB7NHm@tjmaciei-mobl1> Message-ID: > 21 июля 2018 г., в 23:04, Thiago Macieira написал(а): > > On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote: >> 1. IDE integration. I really need the IDE know the correct CXX flags for >> each separate file in my project - that is includes, c++ version and so on. >> Currently i’m using a generated CMake file at my work and the integration >> with Qt Creator is awful, i’m using IDE just as a simple text editor - >> syntax highlighting breaks because IDE can’t find some headers (however, >> goto definition works for them). > > That's already more than what we have for qmake, so I wouldn't put this as a > requirement. It's a nice-to-have. But only qmake works fine with new clang model, other build systems pass incorrect parameters to clang so it can’t compile my files (code model complains about missing std:: classes/functions, however the code compiles so project file is correct) > > The point is that the tool has to be at least in feature parity with qmake and > that includes cross-compilation and IDE support. > >> Yes, CMake has much more users than QBS, however, how many of them will >> volunteer to work with CMake’s Qt Creator integration? 5 people? 10? > > 5 people would be more than what we currently have for either qmake or qbs > today, so seems ok. That’s true, but despite huge CMake community, Qt Creator’s CMake integration still is not in feature-parity with qmake. I had a discussion with one of QBS developer about iOS integration in Qt Creator and he told that Qt Creator uses some qmake hacks that are not viable for QBS (yet). Hacking CMake may be much trickier as codebase is not controlled by Qt community. > >> So the question is - is it easier to port QBS to be built without Qt or to >> use CMake with Qt? > > Again, solving the build is easy. Please look into the requirements at (2). > THAT is a lot harder. And all I'm asking is for experience. I don't want Qt to > be the guinea pig. I used QBS and CMake for building debian packages in 2015 at one of my previous works. All you need for QBS is to use usual makefile based debian/rules files and replace «make install» with «qbs install». Here’s the actual code i used to build my tool (except i replace real package/tool names with «projectname») https://pastebin.com/RbPL8GAq That’s it. You pointing too much attention to the Linux distros and maintainers, which is very important, but you are using wrong arguments. Give those maintainers a good tool and they will be happy. And the «good tool» is not the same as «tool has been used for at least 2 years». People has been using plain makefiles for decades, people has been using autotools for years. But i guess anyone agrees that autotools sucks. The same is for CMake - people are using it because they don’t have any alternative. QBS can become that alternative. In case if it will not be buried alive. Common, how you can compare the tools if you didn’t even used QBS? I’ve been using qmake since 2011 i’ve been using CMake since 2013, i worked both with CMake/QBS to create debian packages, i had to work with GYP in 2016, now i’m using QBS for all of my projects. So i can compare tools not by providing abstract requirements, but from the experience of using all those tools. > > More to the point: I will not be part of the experimentation. Give me a mature > tool. The autotools are mature:) PS: BTW, in first letter i forgot to mention that the company i’m working right now ended up with writing it’s own build tool just because CMake didn’t fit all requirements we need from a build tool. We’ve been using CMake, then we wrap all the CMake mess in a set of small macroses (PROGRAM(name), LIBRARY and so on) and then replaced cmake with the tool that understands only those macroses. I don’t know exact reasons why CMake was dropped (when i came to the company, the only thing left from CMake was the project file names - CMakeLists.txt), however it’s true that CMake has a lot of tricky parts when you start using it. The same is true for Google - why do you think they are experimenting with GYP and GN? CMake just doesn’t fits them very well (neither it will fit Qt or anyone else), but i guess they have no alternative (yet). > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Sun Jul 22 13:12:02 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sun, 22 Jul 2018 13:12:02 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> <2168912.jvzcIB7NHm@tjmaciei-mobl1> Message-ID: Sounds like you have a configuration problem in Qt Creator. I've been using qtc with the clang code model and CMake projects for over a year on various C++11/14/17 projects and everything works fine. $ echo '#include \nint main() { std::string_view s("foo"); }' > main.cpp ; echo 'project(foo CXX)\nset(CMAKE_CXX_STANDARD 17)\nadd_executable(foo main.cpp)' > CMakeLists.txt results for me in correct completion of std::string_view in qtc. ------- Jean-Michaël Celerier http://www.jcelerier.name On Sun, Jul 22, 2018 at 12:57 PM, Иван Комиссаров wrote: > > 21 июля 2018 г., в 23:04, Thiago Macieira > написал(а): > > On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote: > > 1. IDE integration. I really need the IDE know the correct CXX flags for > each separate file in my project - that is includes, c++ version and so on. > Currently i’m using a generated CMake file at my work and the integration > with Qt Creator is awful, i’m using IDE just as a simple text editor - > syntax highlighting breaks because IDE can’t find some headers (however, > goto definition works for them). > > > That's already more than what we have for qmake, so I wouldn't put this as > a > requirement. It's a nice-to-have. > > > But only qmake works fine with new clang model, other build systems pass > incorrect parameters to clang so it can’t compile my files (code model > complains about missing std:: classes/functions, however the code compiles > so project file is correct) > > > The point is that the tool has to be at least in feature parity with qmake > and > that includes cross-compilation and IDE support. > > Yes, CMake has much more users than QBS, however, how many of them will > volunteer to work with CMake’s Qt Creator integration? 5 people? 10? > > > 5 people would be more than what we currently have for either qmake or qbs > today, so seems ok. > > > That’s true, but despite huge CMake community, Qt Creator’s CMake > integration still is not in feature-parity with qmake. > I had a discussion with one of QBS developer about iOS integration in Qt > Creator and he told that Qt Creator uses some qmake hacks that are not > viable for QBS (yet). Hacking CMake may be much trickier as codebase is not > controlled by Qt community. > > > So the question is - is it easier to port QBS to be built without Qt or to > use CMake with Qt? > > > Again, solving the build is easy. Please look into the requirements at > (2). > THAT is a lot harder. And all I'm asking is for experience. I don't want > Qt to > be the guinea pig. > > > I used QBS and CMake for building debian packages in 2015 at one of my > previous works. All you need for QBS is to use usual makefile based > debian/rules files and replace «make install» with «qbs install». > Here’s the actual code i used to build my tool (except i replace real > package/tool names with «projectname») https://pastebin.com/RbPL8GAq > That’s it. You pointing too much attention to the Linux distros and > maintainers, which is very important, but you are using wrong arguments. > Give those maintainers a good tool and they will be happy. And the «good > tool» is not the same as «tool has been used for at least 2 years». People > has been using plain makefiles for decades, people has been using autotools > for years. But i guess anyone agrees that autotools sucks. > The same is for CMake - people are using it because they don’t have any > alternative. QBS can become that alternative. In case if it will not be > buried alive. > Common, how you can compare the tools if you didn’t even used QBS? I’ve > been using qmake since 2011 i’ve been using CMake since 2013, i worked both > with CMake/QBS to create debian packages, i had to work with GYP in 2016, > now i’m using QBS for all of my projects. So i can *compare* tools not by > providing abstract requirements, but from the experience of *using *all > those tools. > > > > More to the point: I will not be part of the experimentation. Give me a > mature > tool. > > > The autotools are mature:) > > PS: BTW, in first letter i forgot to mention that the company i’m working > right now ended up with writing it’s own build tool just because CMake > didn’t fit all requirements we need from a build tool. We’ve been using > CMake, then we wrap all the CMake mess in a set of small macroses > (PROGRAM(name), LIBRARY and so on) and then replaced cmake with the tool > that understands only those macroses. I don’t know exact reasons why CMake > was dropped (when i came to the company, the only thing left from CMake was > the project file names - CMakeLists.txt), however it’s true that CMake has > a lot of tricky parts when you start using it. > > The same is true for Google - why do you think they are experimenting with > GYP and GN? CMake just doesn’t fits them very well (neither it will fit Qt > or anyone else), but i guess they have no alternative (yet). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at kdab.com Sun Jul 22 13:18:43 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Sun, 22 Jul 2018 14:18:43 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: <2718493.K7tGJYoJpL@debian> Hi, În ziua de duminică, 22 iulie 2018, la 12:11:44 EEST, Tobias Hunger a scris: > On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development < > > development at qt-project.org> wrote: > > You really hate QBS don't you ? :) > > Do you have so few arguments for qbs that you need to appeal to emotions? :) If it works why not, I'm using all the weapons I have. :-P > >> Anyway IMHO is more important to have a clean, nice and easy to use syntax > > and > > to be tooling friendly than 1.b. > > Sure you can write toolable build files with qbs, but there is nothing > stopping you writing an unparsable JS mess either. Hehe of course you can write messy JS, but at least it doesn't hurt your eyes when you read it and in the morning you don't wake up screaming. > For QML we needed to define a toolable subset of the language with the UI > files to have any chance at tooling it. For the qbs dialect of QML that has > not been done yet. So I do not consider qbs to be toolable at this point. By tooling friendly I mean basic stuff: - create (sub) projects, this part is mostly handled by QtCreator with the wizards templates, but the build system still needs to add it the the parent project. - add targets (executable, static & dynamic libs) to (sub) projects - add/remove files to a (sub)project target. - get all the info about every source file of the (e.g. all compiler flags), cmake with the server thing can handle this task properly these days. - parse the project and report in an easy for IDE way all the project parts (files, (sub) projects, targets, etc.). Same as above, thanks to cmake-server, QtCreator gets all the info properly. Last time I checked it, QBS can handle all those things not only a few. What QBS is missing are toolable properties (similar with cmake ones) which can be used to turn on/off different parts of the project or set other stuff needed by a big projects like Qt (e.g. git version). Going much deeper than this, we'll have to either create super complicated parsers as you mentioned or we'll have to use xml/json/etc. in a non (easily) readable by humans forms. Cheers, BogDan. From bogdan at kdab.com Sun Jul 22 13:25:53 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Sun, 22 Jul 2018 14:25:53 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <1902788.FOCcjvjzyU@debian> Hi, În ziua de duminică, 22 iulie 2018, la 12:18:06 EEST, Tobias Hunger a scris: > On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier < > > jeanmichael.celerier at gmail.com> wrote: > > +1, I was flabbergasted when the big objection against CMake in Qt 6 > > boiled down to "it does not supports all the architectures that Qt > > supports", > > IIRC the bid showstopper was that CMake does not support building host > tools and the target libraries in one go. > > That requirement was dropped since then in our side. > Begin able to build for multiple platforms at once is a requirement also for Android where you can bundle multiple platforms at once in one package. Most probably Android is not the only one which supports this feature. This feature is already implemented by QBS. Cheers, BogDan. From nevion at gmail.com Sun Jul 22 14:58:26 2018 From: nevion at gmail.com (Jason Newton) Date: Sun, 22 Jul 2018 05:58:26 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: On Sun, Jul 22, 2018 at 3:11 AM Kevin Kofler wrote: > > Jason Newton wrote: > > My conclusion for the build system with the brightest future is bazel > > Looking at this, this build system depends on Python AND Java! They ship > binaries with everything bundled, but that is a huge bloat (and it also does > not help GNU/Linux distributions, which will want to use the system versions > of the languages). Yeah, I think java is the only actual curve ball in there but OpenJDK works just fine and seemingly all they care to use. I think your main concern as bloat would likely be around ~200 or so megabytes of disk space used on linux platforms for your distro to pull that in, in development capable machines (which would pull in copious amounts of devel packages + doc). Python is in most distributions, and I'm hesitant to say integral but it frequently seems installed by default, often relating to package management, and I believe they use the system install for python one all the time. In practice I really have to question how much this matters as hard drive space is so cheap and this really is a maximum of a few hundred megabytes, and they offer builds with it built-in to the binary image to free the user from having to install it. Inline history lesson - I believe they started in python or jython and the GIL or performance caused enough grief getting things fast/scalable so they rewrote the runtime to address these and ended up with a python-like interpreter in java. Also the goto language for things that aren't bazel but are a script are either shell or python, not sure how well they explicitly spell this out but that is how it is. > > I think a build system should have minimal dependencies, and ideally be > written in C++ as Qt itself is. If you require more stuff to build the build > system than to build Qt, something is clearly wrong. > > > -Time tested, running in production environments > > Bazel is still fairly new and adoption is low, especially in the Free > Software world. It is being mostly adopted by "hip" projects rather than the > well-known Free Software projects. In particular, it is not widely used in > the Qt community. Compare: > https://github.com/bazelbuild/bazel/wiki/Bazel-Users > vs.: > https://cmake.org/ ("Notable Applications Using CMake" section). > > There is also little to no documentation on packaging Bazel-using software > for GNU/Linux distributions. E.g., the Fedora wiki does not contain a single > reference to Bazel. (The only 2 results I get with a full-text search are > about a person with that surname.) Fairly new is interesting in this case because it's core is blaze, and that's not new - two other build systems were built trying to copy it. It is a weird case and even towards your later mentioning of their self declaration of beta, I think it bears in mentioning google considers that term differently (google maps, google mail anyone?). However I know they're rewriting c++ code paths under the hood - if you look at build rules though, you'll see not alot is changing there - I've used it for ~ 1 year and I haven't experienced breakage in this way yet, but I would expect it soon as a part of that process - keep in mind we're looking at a long term shift though, not short term. Also have to point out cmake 2->3 was not painless and as usual projects tend stick to a supported range if and when things break and address it with point releases if possible. Can't deny incompatible changes wouldn't come up but I think that's possible for just about any of the options out there. Not quite sure about what the last section is about - distro-made binaries for bazel? I don't think it's generally on their radar (yet) - There are these pages: https://docs.bazel.build/versions/master/install-redhat.html for the centralized install guides. If you want to build it, you'll need to boot-strap it with a prebuilt binary, but building the executable, tar archives, rpms and debs are all supported - building them oneself is fairly trivial and here is the file of interest in terms of targets: https://github.com/bazelbuild/bazel/blob/master/scripts/packages/BUILD , and owning directory contents. Documentation could be better though, but that comes with distros being made more aware of it, which is often a community based thing, or popularity and in terms of distros acknowledging bazel, yes, I don't think there are any. > > > -Ability to build external libraries from source or pull in binary > > libraries - the former offering alot of power that comes with custom > > flags and controlled dependencies for users developing products, and > > the later for distribution like software - the choice is always there > > and low barrier of entry. One can fuse approaches where it makes > > sense. > > GNU/Linux distributions actually want to link against the system libraries, > not pull in binaries (nor library sources) into the package. What I'm saying is you get both and you want to flesh out both, qt actually is caught in the middle of this (precompiled SDK in particular) of packages in c/c++ becoming a thing (see conan, jfrog) - will they have success? I don't know, people desire pip/npm like capabilities to get libraries close to language, distro agnostic and it's something even the standards folk are poked with. By the way, both of those projects are foremost in cmake. Hodgpodge of sources built JIT and precompiled. Multiple hats and installation types have to be considered ontop of platforms/architectures, in particular since Qt tries to work both with FOSS and proprietary software customers. Also as a python user I frequently felt alot of pain trying to work on distributions that want to replace pip (poorly), but anaconda rocks because it is the eject button on when distros can't deal with dependencies as the developers/users/scientists need to - I bring this up because of pip, and the qt installation independent of distro, I think some of the other points I read earlier, for anaconda related packaging, could be related to third parties not themselves offering - I am interesting in hearing about this, maybe in a more private space @Ray Donnelly . . > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From perezmeyer at gmail.com Sun Jul 22 15:16:17 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Sun, 22 Jul 2018 10:16:17 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <43777450.rx45z2Uc3E@dragon> Message-ID: El dom., 22 de jul. de 2018 06:40, Christian Gagneraud escribió: > On 22 July 2018 at 00:42, Kevin Kofler wrote: > > Bogdan Vatra via Development wrote: > >> Anyway IMHO is more important to have a clean, nice and easy to use > syntax > >> and to be tooling friendly than 1.b. > > > > A custom build system is always a major pain point for distributions. A > > circular dependency (what Thiago's 1.b forbids) makes it particularly > > painful. How should we bootstrap new architectures or entirely new > > distributions if we cannot build Qt due to the circular dependency > between > > Qt and its build tool? This is a showstopper. > > How do you build gcc on Debian? Which compiler do you use? How do you > build the afore mentioned compiler in the first place? > Bootstrapping is a natural process in SW dev, and is and has always > been a long meander. Implementation details don't matter. > I think this point needs a clarification (not for Christian, as you can read below). A self-bootstrapeable tarball/source is enough, like qmake in qtbase does. What we packagers do not want is a source A that needs source B to build but source B needs source A (or the same thing by adding more sources in the middle). AFAIK, Debian cannot even be cross-compiled (Debian ports have never > been build this way).... > That's changing quite fast actually, at the point that people are being able to bootstrap archs by cross compiling. We can even cross compile sources using Qt and most (if not all) of Qt itself by using multi-arch. CMake has a special bootstrapping mode, QMake has one, and any other > build tools (can) have their own, this includes Qbs, and many other.. > > IMHO, this self-contained, circular dependency discussion is moot. > As mentioned by Thiago himself, this is a non-problem, it can be > easily solved for most build system that are on the table. > Right. Can we stop for a moment about self/circular dependency and bootstrapping? > Let's move on more serious topics. Well, the difference between self and circular really does makes a change for us packagers. Really. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Jul 22 17:33:24 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Jul 2018 08:33:24 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <1853122.MOu17TZI6a@tjmaciei-mobl1> On Sunday, 22 July 2018 03:31:42 PDT Kevin Kofler wrote: > PS: In addition, https://bazel.build/ itself describes Bazel as "Beta". In > particular, "Bazel is not yet covered by a deprecation policy, may be > subject to backward-incompatible changes, and is missing some features." > > I do not think relying on a beta build system that may change incompatibly > at any time is a good idea. To be fair, it has time to leave that state and provide compatibility. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 22 17:31:51 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Jul 2018 08:31:51 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <1807400.DTfmLMTjGk@tjmaciei-mobl1> Message-ID: <3943789.PFfioXAcbP@tjmaciei-mobl1> On Sunday, 22 July 2018 02:20:04 PDT Christian Gagneraud wrote: > > It's EXACTLY the reason our seniormost engineers spent three days trying > > to > > upgrade TensorFlow in Clear Linux. That's not your junior guy who only > > knows how to run "npn install". We're talking about people who had been > > building stuff on Linux years before you'd ever heard about Linux. > > Clear Linux, hum? Are they re-inventing the wheel? And the hammer, the > nail, and the saw, what have you... We are reinventing the wheel in some things, but in this we're not. We're simply trying to make an RPM .spec file that builds the latest version of TensorFlow. There are at least a dozen other distributions who need to do that, using a 20+-year-old technology (RPM). Specifically, the problem with TensorFlow is that it wants to download its dependencies when you compile it, then compile them at the same time. That can't work because the build servers don't have internet connectivity. https://build.opensuse.org/package/view_file/science:machinelearning/ tensorflow/tensorflow.spec?expand=1 https://github.com/clearlinux-pkgs/tensorflow/blob/master/tensorflow.spec > "Kata Container with Clear Linux"? What an obscure technology, and > what does it has to do with the Qt project and build system in > general? I was replying to the message saying that Bazel would be a good choice by relating our experience. You brought Kata Containers up. If you use containers on Linux and you care about security, you should take a look at it. It's about using the processor's virtual machine hypervisor functionality to make sure the code in the container can't break out of the container, without making a full virtual machine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 22 17:22:53 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Jul 2018 08:22:53 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <3015142.QpK3NUENCd@tjmaciei-mobl1> On Sunday, 22 July 2018 01:57:59 PDT Tobias Hunger wrote: > All these are very reasonable to ask for. I personally would like to add > the following point for consideration: > > 4) Toolable > > A) works with IDE(s) -- preferably more than one Hello Tobias The fact that we have an IDE of ours means this one should be reasonably easy to address, as we can make that IDE work with the tool. So long as the tool is actually toolable, of course. "More than one" would be quite a challenge. > B) Should be easy to hook in static and dynamic code analyzer tools Can you elaborate? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 22 17:20:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Jul 2018 08:20:27 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <2168912.jvzcIB7NHm@tjmaciei-mobl1> Message-ID: <1979361.pednaA0Izs@tjmaciei-mobl1> On Sunday, 22 July 2018 03:57:37 PDT Иван Комиссаров wrote: > That’s it. You pointing too much attention to the Linux distros and > maintainers, which is very important, but you are using wrong arguments. > Give those maintainers a good tool and they will be happy. And the «good > tool» is not the same as «tool has been used for at least 2 years». People > has been using plain makefiles for decades, people has been using autotools > for years. But i guess anyone agrees that autotools sucks. You're right, "good tool" does not mean "tool has been used for 2 years". Yet I stand by what I said: I want a good tool, but *need* experience. The point of 2 years is not to let them fight out to figure out which ones is best. The point is to make sure the kinks are ironed out and that people have dealt with them. Have they figured out how to do debugging when things go wrong? Autoconf produces a very detailed config.log; qmake does a similar one for qtbase, but has the -d -d options that almost always explain to me how things were wrong. CMake is a lot harder and I hate debugging it, but in the worst case I know there are people I can turn to for help. I want to say the same for the tool we choose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tobias.hunger at gmail.com Sun Jul 22 18:31:49 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Jul 2018 18:31:49 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <05E8AB16-B1A1-49A2-BB29-2582EBDA5D70@gmail.com> <2168912.jvzcIB7NHm@tjmaciei-mobl1> Message-ID: On Sun, Jul 22, 2018, 12:58 Иван Комиссаров wrote: > But only qmake works fine with new clang model, other build systems pass > incorrect parameters to clang so it can’t compile my files (code model > complains about missing std:: classes/functions, however the code compiles > so project file is correct) > Please file but reports for those cases then. That *should* work and it does work with all my test projects. That’s true, but despite huge CMake community, Qt Creator’s CMake > integration still is not in feature-parity with qmake. > CMake had never been a first class citizen in creator: Noboby inside the Qt company used cmake in earnest, so nobody cared for CMake support -- once we had rudimentary functionality in place. When I spend some month improving CMake support in creator the feedback was fantastic and there was and still is *lots* of it! There are *LOTS* of people using qt creator and CMake out there! But you are right: Some features are not possible with cmake. This includes most operations that involve modifying CMakeLists.txt files directly, including e.g. adding files to a target. One can hack something that will probably work most of the time, but that is as good as it will get. That is the same situation we also have with qbs by the way: Add some JS into the wrong place and toolability is gone... Do stuff sensibly and all is well. Best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Sun Jul 22 19:34:13 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Jul 2018 19:34:13 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <3015142.QpK3NUENCd@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <3015142.QpK3NUENCd@tjmaciei-mobl1> Message-ID: Hi Thiago, On Sun, Jul 22, 2018, 17:35 Thiago Macieira wrote: > > A) works with IDE(s) -- preferably more than one > > Hello Tobias > > The fact that we have an IDE of ours means this one should be reasonably > easy > to address, as we can make that IDE work with the tool. So long as the > tool is > actually toolable, of course. This is a matter of resources and what we want to spend those on. Creator needs first class support for qmake for years to come. It also needs first class support for CMake as that is what people out there actually use. These two are set for the foreseeable future. When we have a decision on what Qt will use going forward, then that will be added to the mix. "More than one" would be quite a challenge. We can not expect people to drop their preferred set of tools to work on Qt. That is a sure-fire way to reduce contributions from outside of our core community. > B) Should be easy to hook in static and dynamic code analyzer tools > > Can you elaborate? > Most build tools offer to create a build_commands.json file so that some of the clang tools can be used easily. I expect that from any build tool nowadays. Meson offers a "build with address sanitisation" option (and similar ones for UBSAN, etc.) that can just turn on for your project. I would love that, but at the very least compiler-based tools like ASAN and UBSAN should be easy to enable with good documentation on how to do so. A build tool with a track record of empowering developers by making new tools easy to use on existing projects would be welcome. Best regards, Tobias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Jul 22 22:18:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Jul 2018 13:18:05 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <3015142.QpK3NUENCd@tjmaciei-mobl1> Message-ID: <7336317.i9ymxyZGJJ@tjmaciei-mobl1> On Sunday, 22 July 2018 10:34:13 PDT Tobias Hunger wrote: > > "More than one" would be quite a challenge. > > We can not expect people to drop their preferred set of tools to work on > Qt. That is a sure-fire way to reduce contributions from outside of our > core community. Sure, but we compare that to status quo: what is the support out there for qmake? The only IDEs that support it natively are Qt Creator and KDevelop. For Visual Studio and for XCode, qmake itself creates the export, so the tool we choose could do the same. > > B) Should be easy to hook in static and dynamic code analyzer tools > > > > Can you elaborate? > > Most build tools offer to create a build_commands.json file so that some of > the clang tools can be used easily. I expect that from any build tool > nowadays. > > Meson offers a "build with address sanitisation" option (and similar ones > for UBSAN, etc.) that can just turn on for your project. I would love that, > but at the very least compiler-based tools like ASAN and UBSAN should be > easy to enable with good documentation on how to do so. Any build tool MUST have a way for the caller to pass override C and C++ flags. Full stop, no exceptions.[*] Given that, I don't see why the tool must have special support for those compilation flags. It's a nice-to-have, though. Similarly, it's a very nice to have a way to specify which C++ language edition you want, whether you want exceptions and/or RTTI enabled, whether you want warnings turned on and off, etc. [*] and a way that isn't unduly difficult to trigger. Counter-example: Qt's current buildsystem. Look at this build logs: https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ libqt5-qtbase/_log On lines 1056-1059, you see CFLAGS and CXXFLAGS being set. But then if you scan forward in the actual build, you don't see any of them applied. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Sun Jul 22 23:54:14 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 22 Jul 2018 23:54:14 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: <1807400.DTfmLMTjGk@tjmaciei-mobl1> <3943789.PFfioXAcbP@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > Specifically, the problem with TensorFlow is that it wants to download its > dependencies when you compile it, then compile them at the same time. That > can't work because the build servers don't have internet connectivity. +1, this is also a hard, non-negotiable requirement in Fedora. Any build system that requires downloading dependencies at build time is a complete non-starter. The builds would just fail with no way to fix them. Kevin Kofler From perezmeyer at gmail.com Mon Jul 23 01:11:28 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sun, 22 Jul 2018 20:11:28 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <3943789.PFfioXAcbP@tjmaciei-mobl1> Message-ID: <2181407.MrCAnzYKN9@tonks> El domingo, 22 de julio de 2018 18:54:14 -03 Kevin Kofler escribió: > Thiago Macieira wrote: > > Specifically, the problem with TensorFlow is that it wants to download its > > dependencies when you compile it, then compile them at the same time. That > > can't work because the build servers don't have internet connectivity. > > +1, this is also a hard, non-negotiable requirement in Fedora. Any build > system that requires downloading dependencies at build time is a complete > non-starter. The builds would just fail with no way to fix them. Exactly the same goes for Debian and Ubuntu. And it would not surprise me that any other derivative out there. Let me be clear in one thing: if somehow this can be used for Windows instead of convenience copies but disabled for Linux/builders not wanting auto download of stuff then we can agree to have this feature. -- hmm, el enchufe hace chispas... <-- rata ha dejado este servidor ("Leaving"). ouch Visto en #lugfi, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From olszak.tomasz at gmail.com Mon Jul 23 12:52:46 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 23 Jul 2018 12:52:46 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi, I'm resurrecting this thread because it showed me that I can do more with QML (registerConverters). The only missing part was to allow developer to register converter from his custom metatype to QML. I often ended up with making 2 properties e.g: QList cppProperty QVariantList qmlProperty the API was ugly, etc. Then I realized that if we already handle QVariant properly in QML then why not to allow app developer to register converter to e.g. QList -> QVariant And use it in QML engine. I made this simple patch and tested that it works, and is totally enough for my needs. It make my API clean, If I need big performance I do not use QList but rather create model. However for simple, UI, cases it s a great benefit. https://codereview.qt-project.org/#/c/235051 I haven't spent much time on it, probably data from "void *data = QMetaType::create(property.propType());" needs to be deleted after conversion. I is:f you find the solution acceptable I can polish it with your help. Now the main question is: what's wrong with this approach? Would it break QML compiler? I don't see it having big performance issues because a lot of app developer does the same but just inside their app code. pon., 4 cze 2018 o 19:46 Uwe Rathmann napisał(a): > > Hi Tomek, > > > I quickly reviewed QSkinny and it really nicely exposes C++ to Qml. I > > can't see however, how you made e.g. QskVariant::stops readable from > > Qml. Writing stops is possible due to QMetaType::registerConvertes, but > > how you can iterate overs stop from Qml? > > Don't know either, but I'm not the right person to ask when it comes to > JavaScript related issues. > > > PS: I also tried to have the same implementation for C++ and Qt Qml and > > now some classes contains duplicated getters/setters (QVariantList > > instead of QVector). > > Hope it is o.k. to throw in some ideas/experiences, but as my work is not > part of the qt-project I don't want to to misuse this mailing list. > > But if you ( or anyone else ) likes to discuss in more depth what I'm > doing you can always contact me of the list. > > ciao, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aapo.keskimolo at qt.io Wed Jul 25 13:56:23 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Wed, 25 Jul 2018 11:56:23 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin production was updated today at Wed Jul 25 14:28:29 EEST 2018 with new baseline. For CI related issues, you may create bug report as instructed in https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin and/or consult the internal #qtci IRC-channel. See change-list attached for related patches. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180725.log Type: application/octet-stream Size: 60403 bytes Desc: product_baseline_20180725.log URL: From alexander.blasche at qt.io Wed Jul 25 17:12:39 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 25 Jul 2018 15:12:39 +0000 Subject: [Development] =?iso-8859-1?q?Noninating_Andr=E9_de_la_Rocha_for_A?= =?iso-8859-1?q?pprover?= Message-ID: Hi, I'd like to nominate André for approver rights. He has been with us at the TQtC for almost a year. He has mainly contributed to the Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message Support) but you may have seen an occasional iOS fix too. His work: https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z -- Alex From alexander.blasche at qt.io Wed Jul 25 17:12:47 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 25 Jul 2018 15:12:47 +0000 Subject: [Development] Nominating Miguel Costa for Approver Message-ID: Hi, I'd like to nominate Miguel for approver rights. He has been with us at the TQtC for a year. His largest contributions have been to the Visual Studio addin which he properly ported to the latest VS incarnations/APIs. More recently he has started to look at the WinRT port and the Angle integration in particular. His work: https://codereview.qt-project.org/#/q/owner:+miguel.costa,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:+miguel.costa,n,z -- Alex From Shawn.Rutledge at qt.io Wed Jul 25 17:49:13 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 25 Jul 2018 15:49:13 +0000 Subject: [Development] =?iso-8859-1?q?Noninating_Andr=E9_de_la_Rocha_for_?= =?iso-8859-1?q?Approver?= In-Reply-To: References: Message-ID: +1 > On 25 Jul 2018, at 17:12, Alex Blasche wrote: > > Hi, > > I'd like to nominate André for approver rights. > > He has been with us at the TQtC for almost a year. He has mainly contributed to the Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message Support) but you may have seen an occasional iOS fix too. > > His work: > https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z > > His reviews: > https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z > > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Gabriel.deDietrich at qt.io Wed Jul 25 19:16:57 2018 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Wed, 25 Jul 2018 17:16:57 +0000 Subject: [Development] =?utf-8?q?Noninating_Andr=C3=A9_de_la_Rocha_for_Ap?= =?utf-8?q?prover?= In-Reply-To: References: Message-ID: <19CD5F73-30D2-4FA4-AA75-1B6223C7AA7A@qt.io> +1 Disclaimer: André is a colleague of mine at The Qt Company. Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company On Jul 25, 2018, at 8:12 AM, Alex Blasche > wrote: Hi, I'd like to nominate André for approver rights. He has been with us at the TQtC for almost a year. He has mainly contributed to the Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message Support) but you may have seen an occasional iOS fix too. His work: https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Wolff at qt.io Thu Jul 26 07:34:16 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Thu, 26 Jul 2018 07:34:16 +0200 Subject: [Development] Nominating Miguel Costa for Approver In-Reply-To: References: Message-ID: <535ea20f-f40c-379a-74fc-32f3af66ff4d@qt.io> +1... he did a tremendous job with the AddIn (disclaimer: he is sitting next to me in the office) Olli On 25/07/2018 17:12, Alex Blasche wrote: > Hi, > > I'd like to nominate Miguel for approver rights. > > He has been with us at the TQtC for a year. His largest contributions have been to the Visual Studio addin which he properly ported to the latest VS incarnations/APIs. More recently he has started to look at the WinRT port and the Angle integration in particular. > > His work: > https://codereview.qt-project.org/#/q/owner:+miguel.costa,n,z > > His reviews: > https://codereview.qt-project.org/#/q/reviewer:+miguel.costa,n,z > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Oliver.Wolff at qt.io Thu Jul 26 07:35:06 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Thu, 26 Jul 2018 07:35:06 +0200 Subject: [Development] =?utf-8?q?Noninating_Andr=C3=A9_de_la_Rocha_for_Ap?= =?utf-8?q?prover?= In-Reply-To: References: Message-ID: <7645fddd-e1c3-13ce-22f4-8e273e0e71f9@qt.io> +1 (disclaimer: We are sitting in the same office) Olli On 25/07/2018 17:12, Alex Blasche wrote: > Hi, > > I'd like to nominate André for approver rights. > > He has been with us at the TQtC for almost a year. He has mainly contributed to the Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message Support) but you may have seen an occasional iOS fix too. > > His work: > https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z > > His reviews: > https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z > > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at qt.io Thu Jul 26 08:54:57 2018 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Thu, 26 Jul 2018 08:54:57 +0200 Subject: [Development] =?utf-8?q?Noninating_Andr=C3=A9_de_la_Rocha_for_Ap?= =?utf-8?q?prover?= In-Reply-To: References: Message-ID: <21324260-b38e-101f-1b04-5db1b0b9f918@qt.io> Hi, +1 from me, too, (same office though); UI and Pointer message handling were great jobs. Friedemann -- Friedemann Kleint The Qt Company GmbH From vincenthk007 at gmail.com Fri Jul 27 05:15:16 2018 From: vincenthk007 at gmail.com (Vincent Hui) Date: Fri, 27 Jul 2018 11:15:16 +0800 Subject: [Development] What are new features of Qt3D in Qt 5.12? Message-ID: Hi, What are new features of Qt3D in Qt 5.12? Will Rigid body and soft body physics simulation be included? I hope there will be new features of Qt3D in Qt 5.12. Thanks, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From brettg at posteo.net Fri Jul 27 05:23:35 2018 From: brettg at posteo.net (Brett Gilio) Date: Thu, 26 Jul 2018 22:23:35 -0500 Subject: [Development] What are new features of Qt3D in Qt 5.12? In-Reply-To: References: Message-ID: <87a7qduzt4.fsf@posteo.net> Vincent Hui writes:> > What are new features of Qt3D in Qt 5.12? Will Rigid body and > soft body > physics simulation be included? > > I hope there will be new features of Qt3D in Qt 5.12. Hello Vincent, Unless I am mistaken, there should be a Changelog available for a collection such modifications including feature additions available in the Qt3D git repository on the Qt website. Best -- Brett M. Gilio Free Software Foundation, Member https://parabola.nu | https://emacs.org From robert.loehning at qt.io Fri Jul 27 12:54:55 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Fri, 27 Jul 2018 12:54:55 +0200 Subject: [Development] What are new features of Qt3D in Qt 5.12? In-Reply-To: <87a7qduzt4.fsf@posteo.net> References: <87a7qduzt4.fsf@posteo.net> Message-ID: <89d2d80d-2075-d975-0778-1f11ea09eba2@qt.io> Am 27.07.2018 um 05:23 schrieb Brett Gilio: > > Vincent Hui writes:> >> What are new features of Qt3D in Qt 5.12? Will Rigid body and soft body >> physics simulation be included? >> >> I hope there will be new features of Qt3D in Qt 5.12. > > > Hello Vincent, > > Unless I am mistaken, there should be a Changelog available for a > collection such modifications including feature additions available in > the Qt3D git repository on the Qt website. > > Best > > Hello Vincent, Brett, these change logs do not exist yet for 5.12. They are usually written shortly before the release. When we will approach the release, you will find more and more information on https://wiki.qt.io/Qt_5.12_Release Cheers, Robert From tilman.roder at qt.io Fri Jul 27 14:37:22 2018 From: tilman.roder at qt.io (=?iso-8859-1?Q?Tilman_R=F6der?=) Date: Fri, 27 Jul 2018 12:37:22 +0000 Subject: [Development] Requesting Repository For Python Extension Support in QtCreator Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aha_1980 at gmx.de Sat Jul 28 10:56:37 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=C3=A9?=) Date: Sat, 28 Jul 2018 10:56:37 +0200 Subject: [Development] Proposing Samuel Gaist for approver status Message-ID: Hello all, I'd like to propose Samuel as approver. He has been active in the Qt project for ages. He not only provides code changes [0], he is also active reviewing others changes [1]. But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works as moderator and answers plenty of questions every day. Some of his patches arised from forum questions, therefore Samuel perfectly bridges between the end users and the Qt main developers. I think this all qualifies Samuel for the approver status. Best regards, André [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [2] https://forum.qt.io/user/sgaist From szehowe.koh at gmail.com Sat Jul 28 12:55:48 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 28 Jul 2018 18:55:48 +0800 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: On Sat, 28 Jul 2018 at 16:57, André wrote: > > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist +1 from me. I second all the points that André has raised. In addition, Samuel also improves the Qt documentation, and he has been awarded the title of Lifetime Qt Champion. Regards, Sze-Howe From thiago.macieira at intel.com Sat Jul 28 18:50:45 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 28 Jul 2018 09:50:45 -0700 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <2268684.dmmQaUUcSk@tjmaciei-mobl1> On Saturday, 28 July 2018 01:56:37 PDT André wrote: > I'd like to propose Samuel as approver. He has been active in the Qt project > for ages. > > He not only provides code changes [0], he is also active reviewing others > changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where > he works as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly > bridges between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. Another "what? he's not an approver?" case. +1 from me. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From iamsergio at gmail.com Sat Jul 28 20:51:01 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sat, 28 Jul 2018 19:51:01 +0100 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: On Sat, Jul 28, 2018 at 9:56 AM, André wrote: > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. +1 Cheers, Sergio Martins From thiago.macieira at intel.com Sun Jul 29 17:16:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 Jul 2018 08:16:30 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <2365600.H4SCMarA6K@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <1820817.PysAIFrBie@dragon> <2365600.H4SCMarA6K@tjmaciei-mobl1> Message-ID: <15181586.VRj9kvLEzD@tjmaciei-mobl1> On Monday, 16 July 2018 08:50:05 PDT Thiago Macieira wrote: > On Monday, 16 July 2018 00:08:44 PDT Bogdan Vatra via Development wrote: > > The clang support was added and works fine from 5.9. But I think is too > > late to switch NDK for 5.11. > > I'm not asking to change compilers. I am asking whether we can require fixed > NDK headers? No answer. I've marked https://bugreports.qt.io/browse/QTBUG-69173 as unassigned and abandoned the change that would fix. Someone else take care of Android. I'm tired of the buggy libc we have to deal with, the fact that we can't even rely on the fixes from said libc and the fact that there seems to be little attention to this platform from the people who should be the experts. This is not the first time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Sun Jul 29 20:15:38 2018 From: bogdan.vatra at kdab.com (BogDan Vatra) Date: Sun, 29 Jul 2018 21:15:38 +0300 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <15181586.VRj9kvLEzD@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <1820817.PysAIFrBie@dragon> <2365600.H4SCMarA6K@tjmaciei-mobl1> <15181586.VRj9kvLEzD@tjmaciei-mobl1> Message-ID: AFIK qt 5.12 will use ndk r16 or better. On July 29, 2018 6:16:30 PM GMT+03:00, Thiago Macieira wrote: >On Monday, 16 July 2018 08:50:05 PDT Thiago Macieira wrote: >> On Monday, 16 July 2018 00:08:44 PDT Bogdan Vatra via Development >wrote: >> > The clang support was added and works fine from 5.9. But I think is >too >> > late to switch NDK for 5.11. >> >> I'm not asking to change compilers. I am asking whether we can >require fixed >> NDK headers? > >No answer. > >I've marked https://bugreports.qt.io/browse/QTBUG-69173 as unassigned >and >abandoned the change that would fix. > >Someone else take care of Android. I'm tired of the buggy libc we have >to deal >with, the fact that we can't even rely on the fixes from said libc and >the >fact that there seems to be little attention to this platform from the >people >who should be the experts. > >This is not the first time. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Jul 29 21:11:53 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 Jul 2018 12:11:53 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <15181586.VRj9kvLEzD@tjmaciei-mobl1> Message-ID: <6445303.uyRKAmClH8@tjmaciei-mobl1> On Sunday, 29 July 2018 11:15:38 PDT BogDan Vatra via Development wrote: > AFIK qt 5.12 will use ndk r16 or better. The question was for Qt 5.11 using fixed headers. The fix in Bionic happened in January 2015. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Sun Jul 29 21:18:38 2018 From: bogdan.vatra at kdab.com (BogDan Vatra) Date: Sun, 29 Jul 2018 22:18:38 +0300 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <6445303.uyRKAmClH8@tjmaciei-mobl1> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <15181586.VRj9kvLEzD@tjmaciei-mobl1> <6445303.uyRKAmClH8@tjmaciei-mobl1> Message-ID: <94CD83A3-A508-4C98-A02E-33CA35CB94A5@kdab.com> For 5.11 we used 10e and I'm afraid we can't afford to change it without proper testing. Cheers, BogDan. On July 29, 2018 10:11:53 PM GMT+03:00, Thiago Macieira wrote: >On Sunday, 29 July 2018 11:15:38 PDT BogDan Vatra via Development >wrote: >> AFIK qt 5.12 will use ndk r16 or better. > >The question was for Qt 5.11 using fixed headers. > >The fix in Bionic happened in January 2015. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Sun Jul 29 22:36:43 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sun, 29 Jul 2018 17:36:43 -0300 Subject: [Development] LLVM and Qt Message-ID: <2230146.JdTnKv3ITY@tonks> Hi! As now qdoc has gained a dependency on llvm we noted that many Debian ports will not be able to build it anymore, as llvm has (at least for now) no support for them: I would like to know if there is any other place in Qt where it might start requiring llvm to point porters (people behind those archs) where they will be seeing more issues. It would also be pretty nice to know if there is a policy with respect the llvm supported version. As they do not keep ABI compatibility distros normally are forced to ship from two to three versions. As I understand the idea in Debian testing/unstable is to have the latest two always available, sometimes three of them. That already created some issues for us with Qt Creator, as at some point it required a version which was about to be removed. Please note that I am not objecting the use of llvm in any way, although it would be real cool if they kept ABI... but that's not up to us to fix it I guess. Thanks, Lisandro. -- She got her good looks from her father. He's a plastic surgeon. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From kde at carewolf.com Sun Jul 29 22:40:04 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 29 Jul 2018 22:40:04 +0200 Subject: [Development] LLVM and Qt In-Reply-To: <2230146.JdTnKv3ITY@tonks> References: <2230146.JdTnKv3ITY@tonks> Message-ID: <34861838.uZksjlZyTk@twilight> On Sonntag, 29. Juli 2018 22:36:43 CEST Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! As now qdoc has gained a dependency on llvm we noted that many Debian > ports will not be able to build it anymore, as llvm has (at least for now) > no support for them: > > > > > I would like to know if there is any other place in Qt where it might start > requiring llvm to point porters (people behind those archs) where they will > be seeing more issues. > > It would also be pretty nice to know if there is a policy with respect the > llvm supported version. As they do not keep ABI compatibility distros > normally are forced to ship from two to three versions. As I understand the > idea in Debian testing/unstable is to have the latest two always available, > sometimes three of them. That already created some issues for us with Qt > Creator, as at some point it required a version which was about to be > removed. > > Please note that I am not objecting the use of llvm in any way, although it > would be real cool if they kept ABI... but that's not up to us to fix it I > guess. > You only need llvm for qdoc. You can probably remove qdoc on those platforms, and generate the platform independent documentation packages on hosts where it is supported. `Allan From perezmeyer at gmail.com Sun Jul 29 22:47:33 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sun, 29 Jul 2018 17:47:33 -0300 Subject: [Development] LLVM and Qt In-Reply-To: <34861838.uZksjlZyTk@twilight> References: <2230146.JdTnKv3ITY@tonks> <34861838.uZksjlZyTk@twilight> Message-ID: <7339769.mThC6mcgOg@tonks> El domingo, 29 de julio de 2018 17:40:04 -03 Allan Sandfeld Jensen escribió: [snip] Wow, that was fast for a sunday :-) Thanks! > You only need llvm for qdoc. You can probably remove qdoc on those > platforms, and generate the platform independent documentation packages on > hosts where it is supported. Right, there is a porter working on that now. Maybe some app would break in case it embeds the documentation using resources, but that would be strange I think. Non the less the other questions remains, if applicable at all. -- 2: Windows con las funciones que realiza se clasifica como: * Un bug 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 30 05:56:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 Jul 2018 20:56:10 -0700 Subject: [Development] Raising the minimum Android NDK version In-Reply-To: <94CD83A3-A508-4C98-A02E-33CA35CB94A5@kdab.com> References: <4292324.T6dSZakdiv@tjmaciei-mobl1> <6445303.uyRKAmClH8@tjmaciei-mobl1> <94CD83A3-A508-4C98-A02E-33CA35CB94A5@kdab.com> Message-ID: <5290524.vFGJfuxfyW@tjmaciei-mobl1> On Sunday, 29 July 2018 12:18:38 PDT BogDan Vatra via Development wrote: > For 5.11 we used 10e and I'm afraid we can't afford to change it without > proper testing. Thanks. Someone can fix the issue then. I recommend #ifdef Q_OS_ANDROID // Android libc told us for 7 years to use a file Android doesn't have # undef _PATH_MOUNTED # define _PATH_MOUNTED "/proc/mounts" #endif -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 30 06:00:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 29 Jul 2018 21:00:30 -0700 Subject: [Development] LLVM and Qt In-Reply-To: <2230146.JdTnKv3ITY@tonks> References: <2230146.JdTnKv3ITY@tonks> Message-ID: <1982548.xfmXKttzsI@tjmaciei-mobl1> On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > It would also be pretty nice to know if there is a policy with respect the > llvm supported version. As they do not keep ABI compatibility distros > normally are forced to ship from two to three versions. As I understand the > idea in Debian testing/unstable is to have the latest two always available, > sometimes three of them. That already created some issues for us with Qt > Creator, as at some point it required a version which was about to be > removed. Same policy for third-party libraries: we work with the latest, unless that release happened too late in our own release cycle. But where do we get LLVM from on a Mac? Is it from Apple? If so, we may need to keep things working with an old, patched version, in addition to the latest. Or we require an upgrade with Homebrew. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From joerg.bornemann at qt.io Mon Jul 30 08:52:13 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Mon, 30 Jul 2018 08:52:13 +0200 Subject: [Development] Nominating Miguel Costa for Approver In-Reply-To: References: Message-ID: <07351d4d-113b-1b35-f356-f1d6fc7efb60@qt.io> On 07/25/2018 05:12 PM, Alex Blasche wrote: > I'd like to nominate Miguel for approver rights. +1 Disclaimer: He's sitting next to Oliver. Joerg From edward.welbourne at qt.io Mon Jul 30 10:01:51 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 30 Jul 2018 08:01:51 +0000 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: <2268684.dmmQaUUcSk@tjmaciei-mobl1> References: , <2268684.dmmQaUUcSk@tjmaciei-mobl1> Message-ID: On Saturday, 28 July 2018 01:56:37 PDT André wrote: >> I'd like to propose Samuel as approver. He has been active in the Qt project >> for ages. >> >> He not only provides code changes [0], he is also active reviewing others >> changes [1]. >> >> But that's not all: Samuel is *extremly* active in the Qt Forum [2], where >> he works as moderator and answers plenty of questions every day. >> >> Some of his patches arised from forum questions, therefore Samuel perfectly >> bridges between the end users and the Qt main developers. >> >> I think this all qualifies Samuel for the approver status. Thiago Macieira (28 July 2018 18:50) > Another "what? he's not an approver?" case. > > +1 from me. echo ! +1 Eddy. From Shawn.Rutledge at qt.io Mon Jul 30 12:08:38 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 30 Jul 2018 10:08:38 +0000 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <05E8A8F6-61A4-4F70-845E-7D79B2845001@qt.io> +1 > On 28 Jul 2018, at 10:56, André wrote: > > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From robert.loehning at qt.io Mon Jul 30 12:39:59 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Mon, 30 Jul 2018 12:39:59 +0200 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <9795e74f-c3e8-7852-339e-9a574d158c0f@qt.io> Am 28.07.2018 um 10:56 schrieb André: > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > How can he not be an approver?? Thanks for bringing this up, André! +1 Cheers, Robert From Gabriel.deDietrich at qt.io Mon Jul 30 18:42:01 2018 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Mon, 30 Jul 2018 16:42:01 +0000 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <2131555E-574F-4BF8-AB9B-C7644AA7CAE7@qt.io> +1 Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company On Jul 28, 2018, at 1:56 AM, André > wrote: Hello all, I'd like to propose Samuel as approver. He has been active in the Qt project for ages. He not only provides code changes [0], he is also active reviewing others changes [1]. But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works as moderator and answers plenty of questions every day. Some of his patches arised from forum questions, therefore Samuel perfectly bridges between the end users and the Qt main developers. I think this all qualifies Samuel for the approver status. Best regards, André [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [2] https://forum.qt.io/user/sgaist _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Jul 30 18:44:08 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 30 Jul 2018 19:44:08 +0300 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <20711101532969048@sas2-9bd6ba081e5d.qloud-c.yandex.net> +1 28.07.2018, 11:56, "André" : > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From mwoehlke.floss at gmail.com Mon Jul 30 22:30:11 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 30 Jul 2018 16:30:11 -0400 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: 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. 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. (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. 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. > The amount of time that useful work is being performed is greater > than I've observed in large cmake projects, even using ninja (assuming > ninja would work across projects that size, due to frequent make > sensitivities) Um... very few projects don't work with Ninja, and I've seen plenty of very large projects that *do*. > -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. On 2018-07-22 06:11, Kevin Kofler wrote: > There is also little to no documentation on packaging Bazel-using software > for GNU/Linux distributions. E.g., the Fedora wiki does not contain a single > reference to Bazel. There's a *reason* why that's so... -- Matthew From jani.heikkinen at qt.io Tue Jul 31 06:40:34 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 31 Jul 2018 04:40:34 +0000 Subject: [Development] Qt 5.12 feature freeze is getting closer In-Reply-To: References: Message-ID: Hi all, Kindly reminder: Feature freeze will be in effect after 3 weeks (20.8.2018). So please make sure all new features for Qt 5.12 are ready and in 'dev' early enough. And please notify me if there will be any new or any removed submodules for Qt5; at the moment i don't know any changes related to that since Qt 5.11 br, Jani ________________________________________ From: Jani Heikkinen Sent: Wednesday, June 20, 2018 1:14 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: Qt 5.12 feature freeze is getting closer Hi all, Only two months to Qt 5.12 feature freeze, see https://wiki.qt.io/Qt_5.12_Release. And summer vacations will take big part of that remaining period... So at this point we should already know if there will be some new submodule modules in Qt 5.12. We are doing packaging confs etc for 5.12 now so please inform qt.team.releases at qt.io (I am starting my vacation today) immediately if there will be some new in. And of course get the new submodule in qt5 as soon as possible; those really needs to be in before we start soft branching mid August! br, Jani From denis.shienkov at gmail.com Tue Jul 31 08:11:54 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 31 Jul 2018 09:11:54 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <5cb814c3-3429-92e5-eff6-2c913a1fe402@gmail.com> Hi guys, Is there are any list of options from which it is possible to choose? As for me, is it prefferable variant will be *QBS* (it is best from the best). I'm do not like nor CMake, nor QMake, nor Autotools, nor something else. BR, Denis From Shawn.Rutledge at qt.io Tue Jul 31 09:18:32 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 31 Jul 2018 07:18:32 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <024CF558-FF70-4F43-A4B2-83E2FA13B757@qt.io> > On 30 Jul 2018, at 22:30, Matthew Woehlke wrote: > > 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. Speaking of which (and speaking of re-inventing the wheel)… I seem to have a lot of qbs-related files on my system despite the fact that I don’t actively use it. (OK I tried to build some project on github once, one that is already trying to use it.) E.g. under ~/.config/QtProject/qbs/1.10.0 it looks like some meta-info, the kind of stuff that cmake and pkg-config already has: $ cat ~/.config/QtProject/qbs/1.10.0/profiles/qt-4-8-7/modules/Qt/phonon/phonon.qbs import qbs 1.0 import '../QtModule.qbs' as QtModule QtModule { qtModuleName: "phonon" Depends { name: "Qt"; submodules: ['core'] } cpp.defines: ["QT_PHONON_LIB"] cpp.includePaths: ["/usr/include/qt4", "/usr/include/qt4/Phonon"] } I don’t know how it got there, but I prefer to have some understanding of what goes in my .config dir so that I can use a git repo to replicate the important stuff between systems (and ignore the rest, maybe even trash it sometimes). Is there any way that mess can be avoided? I mean really, meta-info about *system* packages going into my home dir, as if qbs could even rely on finding those files there, rather than being installed alongside the system package itself?!? Maybe it’s better to continue depending on pkg-config, since it’s an old standard that we probably shouldn’t drop support for anyway, rather than duplicating it? From abbapoh at gmail.com Tue Jul 31 09:41:33 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 31 Jul 2018 10:41:33 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <024CF558-FF70-4F43-A4B2-83E2FA13B757@qt.io> References: <024CF558-FF70-4F43-A4B2-83E2FA13B757@qt.io> Message-ID: QBS generates Qt Modules file depending on the information that QMake provides about modules installed in the system to make sure you won;t be able to import module that doesn’t exist on your system. According to the fact that you can have multiple versions of Qt (i have 3 Qt versions on my Linux machine) and they may be installed in you home dir, it is logical to store those files in your home dir (.config). Of course, you can safely remove the whole dir, it’s just your personal configuration. Funny that you blaming only QBS about the mess in a home dir:) What disturbs me more is the folders like ~/.dropbox ~/.subversion ~/.designer in the root of my home dir *sign* > 31 июля 2018 г., в 10:18, Shawn Rutledge написал(а): > > >> On 30 Jul 2018, at 22:30, Matthew Woehlke wrote: >> >> 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. > > Speaking of which (and speaking of re-inventing the wheel)… I seem to have a lot of qbs-related files on my system despite the fact that I don’t actively use it. (OK I tried to build some project on github once, one that is already trying to use it.) E.g. under ~/.config/QtProject/qbs/1.10.0 it looks like some meta-info, the kind of stuff that cmake and pkg-config already has: > > $ cat ~/.config/QtProject/qbs/1.10.0/profiles/qt-4-8-7/modules/Qt/phonon/phonon.qbs > import qbs 1.0 > import '../QtModule.qbs' as QtModule > > QtModule { > qtModuleName: "phonon" > Depends { name: "Qt"; submodules: ['core'] } > cpp.defines: ["QT_PHONON_LIB"] > cpp.includePaths: ["/usr/include/qt4", "/usr/include/qt4/Phonon"] > } > > I don’t know how it got there, but I prefer to have some understanding of what goes in my .config dir so that I can use a git repo to replicate the important stuff between systems (and ignore the rest, maybe even trash it sometimes). Is there any way that mess can be avoided? I mean really, meta-info about *system* packages going into my home dir, as if qbs could even rely on finding those files there, rather than being installed alongside the system package itself?!? > > Maybe it’s better to continue depending on pkg-config, since it’s an old standard that we probably shouldn’t drop support for anyway, rather than duplicating it? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Tue Jul 31 10:33:21 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 31 Jul 2018 08:33:21 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <024CF558-FF70-4F43-A4B2-83E2FA13B757@qt.io> Message-ID: > On 31 Jul 2018, at 09:41, Иван Комиссаров wrote: > > QBS generates Qt Modules file depending on the information that QMake provides about modules installed in the system to make sure you won;t be able to import module that doesn’t exist on your system. Files that were dynamically created and that I could delete at any time hardly seem like an authoritative place to check what modules are installed on my system. It’s far more likely that they will be out of date later on when I update or remove a system library. > According to the fact that you can have multiple versions of Qt (i have 3 Qt versions on my Linux machine) and they may be installed in you home dir, it is logical to store those files in your home dir (.config). It still looks like needless duplicate info to me. Besides, installing Qt in my home dir is not at all a standard thing to do (it’s only that the Qt installer does it). The standard thing is to use distro-provided packages. And if it becomes necessary for those packages to include qbs-related metainfo, they will end up under /usr somewhere. But maybe it’s better that qbs learns how to use pkg-config, unless there’s a good reason not to? > Of course, you can safely remove the whole dir, it’s just your personal configuration. > > Funny that you blaming only QBS about the mess in a home dir:) Of course not only qbs. ;-) Browser profiles make a bigger mess for example. > What disturbs me more is the folders like ~/.dropbox ~/.subversion ~/.designer in the root of my home dir *sign* yeah, sigh (but dropbox is an easy thing to avoid) From edward.welbourne at qt.io Tue Jul 31 12:10:11 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 31 Jul 2018 10:10:11 +0000 Subject: [Development] Calendar classes: API review request In-Reply-To: References: , Message-ID: Feature freeze is drawing near, as Jani just reminded us, and Soroush's work on calendar support is in a state that looks (to me) ready to use. Please would those with strong views on API design take a look at [0] and speak up now, so that we don't end up reworking it all during the API review phase of the release. * [0] https://codereview.qt-project.org/182341 This would also be a good time to take a look at Hamed's related work in QML: * https://codereview.qt-project.org/228407 * https://codereview.qt-project.org/188184 Eddy. From Simon.Hausmann at qt.io Tue Jul 31 12:38:00 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 31 Jul 2018 10:38:00 +0000 Subject: [Development] Calendar classes: API review request In-Reply-To: References: , , Message-ID: Hi, I've said this also in the reviews, but perhaps it got lost: My primary concern with this API is that it promotes an unclear ownership model. Typically we have API that is either a sub-class of QObject (where the parent may delete the children, such as QFile) or we have value based classes (such as QDateTime). There is also a slightly less common, third model with explicitly shared types, I think mostly acting as singletons. With QAbstractCalendar there's an entirely new model (which also includes a clone() method). I think that model should reconsidered, but if not, then it needs to be documented and it needs to be clarified how this model applies to the exposure of calendars to QML. Otherwise you easily risk creating dangling pointers (as pointed out in the QML review). A secondary concern is that the API, once submitted, is not extensible. We cannot add new properties without breaking binary compatibility, due to the use of virtual functions in the frontend. I think in the past we've solved this by having a nice front-end API with non-virtual functions (those we can add) and channeling this through to a backend that uses fewer virtual functions but enums (that can be extended) to dispatch. Another alternative is the extension mechanism that we've used with QFile/QIODevice. Simon ________________________________ From: Development on behalf of Edward Welbourne Sent: Tuesday, July 31, 2018 12:10:11 PM To: development at qt-project.org Subject: [Development] Calendar classes: API review request Feature freeze is drawing near, as Jani just reminded us, and Soroush's work on calendar support is in a state that looks (to me) ready to use. Please would those with strong views on API design take a look at [0] and speak up now, so that we don't end up reworking it all during the API review phase of the release. * [0] https://codereview.qt-project.org/182341 This would also be a good time to take a look at Hamed's related work in QML: * https://codereview.qt-project.org/228407 * https://codereview.qt-project.org/188184 Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Tue Jul 31 13:11:05 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Tue, 31 Jul 2018 12:11:05 +0100 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: <3843684.v7fED68053@tjmaciei-mobl1> References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: On 2018-01-19 18:32, Thiago Macieira wrote: > On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: >> Jaroslaw Kobus (19 January 2018 17:09) >> >> > "give" may be confused with "get", which is usually an accessor. I may >> > also think "Am I giving (to QCoreApplication)" or "The >> > QCoreApplication is giving (me)". Maybe it is just a matter of the >> > other verb? Absorb, hand over, hand on, suck in, swallow... >> >> However, we have plenty of take functions, where the caller takes >> ownership from the object on which the method is called; so it makes >> sense that a give function would be the caller giving ownership to the >> object on wich the method is called. >> >> Thus we'd keep child.setParent(newParent), since the child doesn't >> take >> ownership of the parent; but QMainWindow's setCentralWidget() would >> become giveCentralWidget(), matching its takeCentralWidget(). This >> would save the search for its doc, to find that it does indeed take >> ownership. >> >> The signature is, in any case, always sufficient to make clear that a >> give()r isn't a get()ter. > > Let's stop the discussion about method *naming* right here. We're not > going to > change hundreds of getters and setters now or even in Qt 6. > > Let's instead find a solution that either uses macros or uses simple > binary- > compatible pointer wrappers like GST. > > And be careful with template functions. Changing from T to Something > may > change what gets deduced. Nuno experienced a crash [1] which could have been easily caught by a compiler plugin or clang-tidy if we used gsl::owner or similar. So to try to move things forward I asked Marc to restore his gsl::owner change [2]. 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. [1] http://lists.qt-project.org/pipermail/interest/2018-July/030530.html [2] https://codereview.qt-project.org/#/c/178107/ Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From alexei.fedotov at gmail.com Tue Jul 31 13:12:52 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 31 Jul 2018 14:12:52 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: <95151508.J85BQgSu05@tjmaciei-mobl1> References: <190050597.bTpa5menfU@tjmaciei-mobl1> <95151508.J85BQgSu05@tjmaciei-mobl1> Message-ID: Hi Thiago, You wrote, > you need a full, absolute Windows path for the prefix. I tried the following: ./configure -developer-build -debug -shared -platform win32-g++ -prefix D:/Qt/5.11/arm -device linux-beagleboard-g++ -device-option CROSS_COMPILE=/d/compilers/gcc-linaro-6.4.1-2017.11-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /d/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihf -opensource -confirm-license -v -nomake examples -nomake tests -qt-zlib -no-opengl -qt-libpng -no-eglfs -no-xcb -no-accessibility -skip 3d -skip activeqt -skip androidextras -skip canvas3d -skip connectivity -skip datavis3d -skip declarative -skip doc -skip docgallery -skip enginio -skip feedback -skip gamepad -skip graphicaleffects -skip imageformats -skip location -skip macextras -skip multimedia -skip networkauth -skip pim -skip purchasing -skip qa -skip quick1 -skip quickcontrols -skip quickcontrols2 -skip remoteobjects -skip repotools -skip script -skip scxml -skip sensors -skip serialbus -skip serialport -skip speech -skip svg -skip systems -skip tools -skip translations -skip virtualkeyboard -skip webchannel -skip webengine -skip webglplugin -skip websockets -skip webview -skip winextras -skip x11extras -skip xmlpatterns -no-openvg -no-qml-debug -no-openssl -no-pch As a result, I get the following during installation stage: D:/QtBuild/qtlast.new/qt5/qtbase/bin/qmake.exe -install qinstall D:/QtBuild/qtlast.new/qt5/qtcharts/mkspecs/modules-inst/qt_lib_charts_private.pri D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm/mkspecs/modules/qt_lib_charts_private.pri How can I avoid combining sysroot and prefix into "D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm"? I'm using ActivePerl v5.26.1 -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Mar 13, 2018 at 6:23 PM, Thiago Macieira wrote: > On Tuesday, 13 March 2018 02:18:42 PDT Alexei Fedotov wrote: >> The build finally passed for me after replacing perl with ActivePerl >> and skipping "qtscript". I'm currently trying to figure out how >> -prefix works for MSYS. > > It should be the same as everything else, provided you're using ActivePerl. > Because of that, no Qt application or script will know about MSYS mounts, so > you need a full, absolute Windows path for the prefix. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Tue Jul 31 13:16:18 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 31 Jul 2018 11:16:18 +0000 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <190050597.bTpa5menfU@tjmaciei-mobl1> <95151508.J85BQgSu05@tjmaciei-mobl1>, Message-ID: Hi, You might be looking for the -extprefix parameter of configure :) Simon ________________________________ From: Development on behalf of Alexei Fedotov Sent: Tuesday, July 31, 2018 1:12:52 PM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] Fwd: qrandom.cpp build problem: please advise Hi Thiago, You wrote, > you need a full, absolute Windows path for the prefix. I tried the following: ./configure -developer-build -debug -shared -platform win32-g++ -prefix D:/Qt/5.11/arm -device linux-beagleboard-g++ -device-option CROSS_COMPILE=/d/compilers/gcc-linaro-6.4.1-2017.11-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /d/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihf -opensource -confirm-license -v -nomake examples -nomake tests -qt-zlib -no-opengl -qt-libpng -no-eglfs -no-xcb -no-accessibility -skip 3d -skip activeqt -skip androidextras -skip canvas3d -skip connectivity -skip datavis3d -skip declarative -skip doc -skip docgallery -skip enginio -skip feedback -skip gamepad -skip graphicaleffects -skip imageformats -skip location -skip macextras -skip multimedia -skip networkauth -skip pim -skip purchasing -skip qa -skip quick1 -skip quickcontrols -skip quickcontrols2 -skip remoteobjects -skip repotools -skip script -skip scxml -skip sensors -skip serialbus -skip serialport -skip speech -skip svg -skip systems -skip tools -skip translations -skip virtualkeyboard -skip webchannel -skip webengine -skip webglplugin -skip websockets -skip webview -skip winextras -skip x11extras -skip xmlpatterns -no-openvg -no-qml-debug -no-openssl -no-pch As a result, I get the following during installation stage: D:/QtBuild/qtlast.new/qt5/qtbase/bin/qmake.exe -install qinstall D:/QtBuild/qtlast.new/qt5/qtcharts/mkspecs/modules-inst/qt_lib_charts_private.pri D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm/mkspecs/modules/qt_lib_charts_private.pri How can I avoid combining sysroot and prefix into "D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm"? I'm using ActivePerl v5.26.1 -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Mar 13, 2018 at 6:23 PM, Thiago Macieira wrote: > On Tuesday, 13 March 2018 02:18:42 PDT Alexei Fedotov wrote: >> The build finally passed for me after replacing perl with ActivePerl >> and skipping "qtscript". I'm currently trying to figure out how >> -prefix works for MSYS. > > It should be the same as everything else, provided you're using ActivePerl. > Because of that, no Qt application or script will know about MSYS mounts, so > you need a full, absolute Windows path for the prefix. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.fedotov at gmail.com Tue Jul 31 13:17:42 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Tue, 31 Jul 2018 14:17:42 +0300 Subject: [Development] Fwd: qrandom.cpp build problem: please advise In-Reply-To: References: <190050597.bTpa5menfU@tjmaciei-mobl1> <95151508.J85BQgSu05@tjmaciei-mobl1> Message-ID: Thanks, Simon! -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ On Tue, Jul 31, 2018 at 2:16 PM, Simon Hausmann wrote: > Hi, > > > You might be looking for the -extprefix parameter of configure :) > > > > Simon > > ________________________________ > From: Development > on behalf of Alexei Fedotov > Sent: Tuesday, July 31, 2018 1:12:52 PM > To: Thiago Macieira > Cc: development at qt-project.org > Subject: Re: [Development] Fwd: qrandom.cpp build problem: please advise > > Hi Thiago, > > You wrote, >> you need a full, absolute Windows path for the prefix. > > > I tried the following: > ./configure -developer-build -debug -shared -platform win32-g++ > -prefix D:/Qt/5.11/arm -device linux-beagleboard-g++ -device-option > CROSS_COMPILE=/d/compilers/gcc-linaro-6.4.1-2017.11-i686-mingw32_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- > -sysroot /d/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihf > -opensource -confirm-license -v -nomake examples -nomake tests > -qt-zlib -no-opengl -qt-libpng -no-eglfs -no-xcb -no-accessibility > -skip 3d -skip activeqt -skip androidextras -skip canvas3d -skip > connectivity -skip datavis3d -skip declarative -skip doc -skip > docgallery -skip enginio -skip feedback -skip gamepad -skip > graphicaleffects -skip imageformats -skip location -skip macextras > -skip multimedia -skip networkauth -skip pim -skip purchasing -skip qa > -skip quick1 -skip quickcontrols -skip quickcontrols2 -skip > remoteobjects -skip repotools -skip script -skip scxml -skip sensors > -skip serialbus -skip serialport -skip speech -skip svg -skip systems > -skip tools -skip translations -skip virtualkeyboard -skip webchannel > -skip webengine -skip webglplugin -skip websockets -skip webview -skip > winextras -skip x11extras -skip xmlpatterns -no-openvg -no-qml-debug > -no-openssl -no-pch > > > As a result, I get the following during installation stage: > D:/QtBuild/qtlast.new/qt5/qtbase/bin/qmake.exe -install qinstall > D:/QtBuild/qtlast.new/qt5/qtcharts/mkspecs/modules-inst/qt_lib_charts_private.pri > D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm/mkspecs/modules/qt_lib_charts_private.pri > > How can I avoid combining sysroot and prefix into > "D:/compilers/sysroot-glibc-linaro-2.25-2017.11-arm-linux-gnueabihfD:/Qt/5.11/arm"? > > I'm using ActivePerl v5.26.1 > > -- > Carry a towel > http://dataved.ru/ > +7 916 562 8095 > > [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ > [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings > [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ > > > On Tue, Mar 13, 2018 at 6:23 PM, Thiago Macieira > wrote: >> On Tuesday, 13 March 2018 02:18:42 PDT Alexei Fedotov wrote: >>> The build finally passed for me after replacing perl with ActivePerl >>> and skipping "qtscript". I'm currently trying to figure out how >>> -prefix works for MSYS. >> >> It should be the same as everything else, provided you're using >> ActivePerl. >> Because of that, no Qt application or script will know about MSYS mounts, >> so >> you need a full, absolute Windows path for the prefix. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Tue Jul 31 13:43:36 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 31 Jul 2018 11:43:36 +0000 Subject: [Development] Symbol clashes with static Qt libraries Message-ID: Hi, I'm wondering how we can avoid symbol clashes in static Qt libs + user code. Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG-67692 : We have the convention to name logging categories (which are actually functions) with 'lc', such as 'lcCanvas'. Since logging categories shouldn't be exported, this is fine for dynamic libs. However, for static builds of Qt, the symbol might clash with symbols of the same name from other libraries / user code, potentially resulting in linker errors. (And no, we can't mark the logging category objects as static / in an anonymous namespace because they can be pre-declared by Q_DECLARE_LOGGING_CATEGORY). Note also that the logging categories are by far not the only non-prefixed symbols that might cause clashes when statically linking. See https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that don't contain a q or Q , for a static Qt build of mine. I can think of 3 approaches to tackle this: a) Prefix all symbols with 'q', like we do for exported symbols. This requires some bigger patches. See e.g. https://codereview.qt-project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase. b) Advise people to always configure static Qt in a namespace (-qtnamespace). This should fix it for symbols at least in our own code. Maybe we should make it even the default for static builds in Qt 6? c) Look into tricks like 'objcopy --localize-hidden' to hide symbols. This would probably require some major hackery in the build system. No idea whether this is supported also on other platforms, and how hard it would be to pull it off. I'm not volunteering 😉 I guess I'm not the first one who looks into this, so I'm happy to hear advice/opinions 😊 Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From eric.lemanissier at gmail.com Tue Jul 31 13:53:35 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Tue, 31 Jul 2018 13:53:35 +0200 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: +1 Le mar. 31 juil. 2018 à 13:11, Sérgio Martins via Development < development at qt-project.org> a écrit : > On 2018-01-19 18:32, Thiago Macieira wrote: > > On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: > >> Jaroslaw Kobus (19 January 2018 17:09) > >> > >> > "give" may be confused with "get", which is usually an accessor. I may > >> > also think "Am I giving (to QCoreApplication)" or "The > >> > QCoreApplication is giving (me)". Maybe it is just a matter of the > >> > other verb? Absorb, hand over, hand on, suck in, swallow... > >> > >> However, we have plenty of take functions, where the caller takes > >> ownership from the object on which the method is called; so it makes > >> sense that a give function would be the caller giving ownership to the > >> object on wich the method is called. > >> > >> Thus we'd keep child.setParent(newParent), since the child doesn't > >> take > >> ownership of the parent; but QMainWindow's setCentralWidget() would > >> become giveCentralWidget(), matching its takeCentralWidget(). This > >> would save the search for its doc, to find that it does indeed take > >> ownership. > >> > >> The signature is, in any case, always sufficient to make clear that a > >> give()r isn't a get()ter. > > > > Let's stop the discussion about method *naming* right here. We're not > > going to > > change hundreds of getters and setters now or even in Qt 6. > > > > Let's instead find a solution that either uses macros or uses simple > > binary- > > compatible pointer wrappers like GST. > > > > And be careful with template functions. Changing from T to Something > > may > > change what gets deduced. > > > Nuno experienced a crash [1] which could have been easily caught by a > compiler plugin or clang-tidy if we used gsl::owner or similar. > > So to try to move things forward I asked Marc to restore his gsl::owner > change [2]. > > 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. > > > > [1] http://lists.qt-project.org/pipermail/interest/2018-July/030530.html > [2] https://codereview.qt-project.org/#/c/178107/ > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090 <+46%20563%2054%2000%2090>, USA > +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tor.arne.Vestbo at qt.io Tue Jul 31 14:00:47 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 31 Jul 2018 12:00:47 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: > On 31 Jul 2018, at 13:43, Kai Koehne wrote: > > I can think of 3 approaches to tackle this: > > a) Prefix all symbols with 'q', like we do for exported symbols. > > This requires some bigger patches. See e.g. https://codereview.qt-project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase. > > b) Advise people to always configure static Qt in a namespace (-qtnamespace). > > This should fix it for symbols at least in our own code. Maybe we should make it even the default for static builds in Qt 6? > > c) Look into tricks like 'objcopy --localize-hidden' to hide symbols. > > This would probably require some major hackery in the build system. No idea whether this is supported also on other platforms, and how hard it would be to pull it off. I'm not volunteering 😉 > > I guess I'm not the first one who looks into this, so I'm happy to hear advice/opinions 😊 a) seems very limiting on our own work, I prefer b) or c) Tor Arne From mitch.curtis at qt.io Tue Jul 31 14:06:38 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 31 Jul 2018 12:06:38 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Kai Koehne > Sent: Tuesday, 31 July 2018 1:44 PM > To: development at qt-project.org > Subject: [Development] Symbol clashes with static Qt libraries > > Hi, > > I'm wondering how we can avoid symbol clashes in static Qt libs + user code. > > Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG- > 67692 : We have the convention to name logging categories (which are > actually functions) with 'lc', such as 'lcCanvas'. Since logging categories > shouldn't be exported, this is fine for dynamic libs. However, for static builds > of Qt, the symbol might clash with symbols of the same name from other > libraries / user code, potentially resulting in linker errors. > > (And no, we can't mark the logging category objects as static / in an > anonymous namespace because they can be pre-declared by > Q_DECLARE_LOGGING_CATEGORY). > > Note also that the logging categories are by far not the only non-prefixed > symbols that might cause clashes when statically linking. See > https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that > don't contain a q or Q , for a static Qt build of mine. > > I can think of 3 approaches to tackle this: > > a) Prefix all symbols with 'q', like we do for exported symbols. > > This requires some bigger patches. See e.g. https://codereview.qt- > project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in > qtbase. > > b) Advise people to always configure static Qt in a namespace (- > qtnamespace). > > This should fix it for symbols at least in our own code. Maybe we should > make it even the default for static builds in Qt 6? This one is a nice compromise, in that it's just an extra argument to pass to configure. Though, like you said, the issue is making people aware of it. Are there any downsides to doing this by default? > c) Look into tricks like 'objcopy --localize-hidden' to hide symbols. > > This would probably require some major hackery in the build system. No idea > whether this is supported also on other platforms, and how hard it would be > to pull it off. I'm not volunteering 😉 > > I guess I'm not the first one who looks into this, so I'm happy to hear > advice/opinions 😊 > > Kai > > -- > Kai Koehne, Senior Manager R&D | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B > > The Future is Written with Qt > www.qtworldsummit.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Jul 31 14:25:21 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 31 Jul 2018 12:25:21 +0000 Subject: [Development] Calendar classes: API review request In-Reply-To: References: , , , Message-ID: Simon Hausmann (31 July 2018 12:38) > I've said this also in the reviews, but perhaps it got lost: 'fraid so. It's been a long review ... and gerrit's not good at helping us find which comments haven't been addressed. > My primary concern with this API is that it promotes an unclear > ownership model. hmm ... this is partly a symptom of most QAbstractCalendar instances being dataless. Each calendar has different code to implement its behaviour. Or, to put it another way, the vtable is the data. Admittedly, I can imagine uses for derived classes that do have data (e.g. for historians of Europe, taking into account the use of Julian for part of history, Gregorian for other parts, with diverse dates for the transition - and some foibles in between), so we should make it possible for them to have data. > Typically we have API that is either a sub-class of QObject (where the > parent may delete the children, such as QFile) or we have value based > classes (such as QDateTime). There is also a slightly less common, > third model with explicitly shared types, I think mostly acting as > singletons. All of which is mostly about how *the data* is shared. > With QAbstractCalendar there's an entirely new model (which also > includes a clone() method). I think that model should [be] > reconsidered, Can you suggest an alternative ? > but if not, then it needs to be documented and it needs to be > clarified how this model applies to the exposure of calendars to > QML. Otherwise you easily risk creating dangling pointers (as pointed > out in the QML review). > A secondary concern is that the API, once submitted, is not > extensible. We cannot add new properties without breaking binary > compatibility, due to the use of virtual functions in the frontend. Again, please suggest some good ways to do this for the case of calendars, where only rather obscure ones have any data; the differences among widely-used calendars are all in code. > I think in the past we've solved this by having a nice front-end API > with non-virtual functions (those we can add) and channeling this > through to a backend that uses fewer virtual functions but enums (that > can be extended) to dispatch. The problem with that is that you're stuck with the calendars that Qt ships. We're never going to ship every calendar that the long tail of potential users might want. We can probably manage the dozen-or-two calendars that the ECMAScript spec mentions in this context, but I want it to be easy for some minority population to be able to implement their own calendar and have Qt transparently use it. The present design supports that. As an example of the long tail, AIUI, a fully faithful implementation of the islamic calendar (as distinct from the fairly widely-adopted "civil" islamic calendar) needs a distinct calendar for each community. It would, IIUC, need data about the user's (community's) local ephemrides (when, exactly, the full or new moon is seen rising there, each month); and I want to leave open the option of some population, who want it, doing that for themselves without us having to take in patches for them to get what they want. There are likewise variants of the Julian calendar still in use by some communities - each its own variant - and I want to let them do their thing in their diverse own ways without us needing to take in patches. Then, as alluded to above, there's the historians ... > Another alternative is the extension mechanism that we've used with > QFile/QIODevice. I don't know that one. I just know that there's a bewildering tangle of abstractions behind QFile, seemingly to handle different file systems, that I sometimes manage to make enough sense of to fix things. I hope we can avoid having such vast complexity for calendars. They're not (individually) actually that complicated (well, except for France and Sweden a couple of centuries ago); its the variations between them that complicate life. All of the extension mechanisms you talk about depend on us writing yet another back-end for each supported case. With calendars, it must be possible for some community to support its own, without needing us to know about it or do more than provide the infrastructure theirs slots into. So yes, the thing I neglected to mention in my previous mail is: do we have any suggestions for how to design an API that'll let app authors implement the calendars they want to support (for their possibly very minority user-bases) and have them work transparently with Qt, just as well as any other calendar that we support ? Bonus points if there's a way for app-authors to implement a plugin API that lets several of them share the same plugin-implemented calendars (without us having to care how they do it). The present design does support all of that. Using a classic (but not-so-Qt-ish) C++ virtual method API. Eddy. From simon.hausmann at qt.io Tue Jul 31 14:34:58 2018 From: simon.hausmann at qt.io (Simon Hausmann) Date: Tue, 31 Jul 2018 14:34:58 +0200 Subject: [Development] Calendar classes: API review request In-Reply-To: References: Message-ID: <1550986.sEj2LahhzR@ubuntu> On Dienstag, 31. Juli 2018 14:25:21 CEST Edward Welbourne wrote: > > My primary concern with this API is that it promotes an unclear > > ownership model. > > hmm ... this is partly a symptom of most QAbstractCalendar instances > being dataless. Each calendar has different code to implement its > behaviour. Or, to put it another way, the vtable is the data. > > Admittedly, I can imagine uses for derived classes that do have data > (e.g. for historians of Europe, taking into account the use of Julian > for part of history, Gregorian for other parts, with diverse dates for > the transition - and some foibles in between), so we should make it > possible for them to have data. > > > Typically we have API that is either a sub-class of QObject (where the > > parent may delete the children, such as QFile) or we have value based > > classes (such as QDateTime). There is also a slightly less common, > > third model with explicitly shared types, I think mostly acting as > > singletons. > > All of which is mostly about how *the data* is shared. > > > With QAbstractCalendar there's an entirely new model (which also > > includes a clone() method). I think that model should [be] > > reconsidered, > > Can you suggest an alternative ? If you are sure that there is no data to be dealt with, that the calendars are free of state, then they should probably become singletons. You can still have a factory on the backend, but for the users of API there would be only pointers to calendar objects that are supposed to remain valid for the life time of the program. > > but if not, then it needs to be documented and it needs to be > > clarified how this model applies to the exposure of calendars to > > QML. Otherwise you easily risk creating dangling pointers (as pointed > > out in the QML review). > > > > A secondary concern is that the API, once submitted, is not > > extensible. We cannot add new properties without breaking binary > > compatibility, due to the use of virtual functions in the frontend. > > Again, please suggest some good ways to do this for the case of > calendars, where only rather obscure ones have any data; the differences > among widely-used calendars are all in code. My preference is the nice-frontend-enum-on-the-backend approach. > > I think in the past we've solved this by having a nice front-end API > > with non-virtual functions (those we can add) and channeling this > > through to a backend that uses fewer virtual functions but enums (that > > can be extended) to dispatch. > > The problem with that is that you're stuck with the calendars that Qt > ships. We're never going to ship every calendar that the long tail of > potential users might want. We can probably manage the dozen-or-two > calendars that the ECMAScript spec mentions in this context, but I want > it to be easy for some minority population to be able to implement their > own calendar and have Qt transparently use it. The present design > supports that. Why does such a separation impose limitations on the API? > As an example of the long tail, AIUI, a fully faithful implementation of > the islamic calendar (as distinct from the fairly widely-adopted "civil" > islamic calendar) needs a distinct calendar for each community. It > would, IIUC, need data about the user's (community's) local ephemrides > (when, exactly, the full or new moon is seen rising there, each month); > and I want to leave open the option of some population, who want it, > doing that for themselves without us having to take in patches for them > to get what they want. There are likewise variants of the Julian > calendar still in use by some communities - each its own variant - and I > want to let them do their thing in their diverse own ways without us > needing to take in patches. Then, as alluded to above, there's the > historians ... > > > Another alternative is the extension mechanism that we've used with > > QFile/QIODevice. > > I don't know that one. It's best demonstrated with the map support in the resource file engine: http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/ qresource.cpp#n1482 A virtual function in the back-end that is lower-level API (not so nice to use) but extensible within our constraints. On the frontend the API is nice (QFile::map) and it was possible to add this while maintaining binary compatibility. It's as if QFile got a new virtual function, except it didn't :) > I just know that there's a bewildering tangle of > abstractions behind QFile, seemingly to handle different file systems, > that I sometimes manage to make enough sense of to fix things. I hope > we can avoid having such vast complexity for calendars. They're not > (individually) actually that complicated (well, except for France and > Sweden a couple of centuries ago); its the variations between them that > complicate life. > > All of the extension mechanisms you talk about depend on us writing yet > another back-end for each supported case. With calendars, it must be > possible for some community to support its own, without needing us to > know about it or do more than provide the infrastructure theirs slots > into. > > So yes, the thing I neglected to mention in my previous mail is: do we > have any suggestions for how to design an API that'll let app authors > implement the calendars they want to support (for their possibly very > minority user-bases) and have them work transparently with Qt, just as > well as any other calendar that we support ? Bonus points if there's a > way for app-authors to implement a plugin API that lets several of them > share the same plugin-implemented calendars (without us having to care > how they do it). The present design does support all of that. > Using a classic (but not-so-Qt-ish) C++ virtual method API. I don't see a way around achieving this without Qt declaring an interface that contains the features it expects the app author supplied calendar to implement. If we want both, ease of use of calendar API itself as well ease of supplying custom calendars to Qt, then we may have to settle for an API that is less convenient to use but extensible without breaking source and binary compatibility perhaps? Simon From giuseppe.dangelo at kdab.com Tue Jul 31 14:38:17 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 31 Jul 2018 14:38:17 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> On 31/07/18 14:06, Mitch Curtis wrote: > This one is a nice compromise, in that it's just an extra argument to pass to configure. Though, like you said, the issue is making people aware of it. > > Are there any downsides to doing this by default? 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... My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From Simon.Hausmann at qt.io Tue Jul 31 14:46:44 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 31 Jul 2018 12:46:44 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: Hi, I recall that when we first discovered this issue - many many years ago - we introduced the tst_symbols auto-test (with Harald). Today it lives in the qtqa repo and it's run for every module. It serves the purpose of verifying that we don't have unprefixed exported symbols. Since this is hard to get right, the test itself has a fair amount of heuristics in place, but I think in principle it gets it right. At the time when we introduced the test, ELF visibility was not a thing yet on Linux (where this test is limited to). That's why it worked. When we started using ELF visibility, things go easier for our users on Linux, but the test stopped protecting us from the issue that remains in static builds. 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. 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. It however does not protect us from the issue on Windows and macOS, but it covers the cross-platform code. It's not perfect, but I think we can improve the situation that we've been living with for many years considerably with minimal effort. Simon ________________________________ From: Development on behalf of Kai Koehne Sent: Tuesday, July 31, 2018 1:43:36 PM To: development at qt-project.org Subject: [Development] Symbol clashes with static Qt libraries Hi, I'm wondering how we can avoid symbol clashes in static Qt libs + user code. Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG-67692 : We have the convention to name logging categories (which are actually functions) with 'lc', such as 'lcCanvas'. Since logging categories shouldn't be exported, this is fine for dynamic libs. However, for static builds of Qt, the symbol might clash with symbols of the same name from other libraries / user code, potentially resulting in linker errors. (And no, we can't mark the logging category objects as static / in an anonymous namespace because they can be pre-declared by Q_DECLARE_LOGGING_CATEGORY). Note also that the logging categories are by far not the only non-prefixed symbols that might cause clashes when statically linking. See https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that don't contain a q or Q , for a static Qt build of mine. I can think of 3 approaches to tackle this: a) Prefix all symbols with 'q', like we do for exported symbols. This requires some bigger patches. See e.g. https://codereview.qt-project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase. b) Advise people to always configure static Qt in a namespace (-qtnamespace). This should fix it for symbols at least in our own code. Maybe we should make it even the default for static builds in Qt 6? c) Look into tricks like 'objcopy --localize-hidden' to hide symbols. This would probably require some major hackery in the build system. No idea whether this is supported also on other platforms, and how hard it would be to pull it off. I'm not volunteering 😉 I guess I'm not the first one who looks into this, so I'm happy to hear advice/opinions 😊 Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Tue Jul 31 14:51:41 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 31 Jul 2018 14:51:41 +0200 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: 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. * Even if we consider talking about the GSL too much of a "distraction" in the docs, we can simply add our own qOwner type alias, with identical semantics, and document what it does and what it means in signatures. * 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. At least, it's one more safeguard against adding functions that take/return pointers and don't clearly document the ownership. 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 :-( My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From edward.welbourne at qt.io Tue Jul 31 14:58:19 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 31 Jul 2018 12:58:19 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> References: , <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> Message-ID: Kai Koehne (Tuesday, 31 July 2018 1:44 PM) >>> b) Advise people to always configure static Qt in a namespace (- >>> qtnamespace). >>> >>> This should fix it for symbols at least in our own code. Maybe we should >>> make it even the default for static builds in Qt 6? On 31/07/18 14:06, Mitch Curtis wrote: >> This one is a nice compromise, in that it's just an extra argument to pass to configure. Though, like you said, the issue is making people aware of it. >> >> Are there any downsides to doing this by default? 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; and I guess apps using them would need to make source changes in order to switch to their namespaced form, or override the default of them being namespaced. What other problem(s) had you in mind ? Eddy. From khuram.ali at aim.com Tue Jul 31 15:00:29 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 09:00:29 -0400 Subject: [Development] Calendar classes: API review request In-Reply-To: Message-ID: <164f06cf162-c8b-1a261@webjas-vab007.srv.aolmail.net> Dear All, I am new to Qt and trying to build it from source using MinGw_64. However, i am getting an error as below, qtbase/src/corelib/global/qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ C:/Qt/5.11.1/mingw8.1_64/src/qtbase/src/corelib/global/qglobal.cpp:3333:5: note: suggested alternative: '_wgetenv' _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ _wgetenv mingw32-make: *** [Makefile:360: qglobal.o] Error 1 I tried to find any clue online but seems that it is not very frequent. Any help would be highly appreciated. Thank you! Regards, Khuram Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuram.ali at aim.com Tue Jul 31 15:01:43 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 09:01:43 -0400 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <164f06cf162-c8b-1a261@webjas-vab007.srv.aolmail.net> Message-ID: <164f06e128a-c86-6547@webjas-vae032.srv.aolmail.net> with correct subject line. Regards, Khuram Ali -----Original Message----- From: Khuram Ali via Development To: development Sent: Tue, Jul 31, 2018 3:00 pm Subject: Re: [Development] Calendar classes: API review request Dear All, I am new to Qt and trying to build it from source using MinGw_64. However, i am getting an error as below, qtbase/src/corelib/global/qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ C:/Qt/5.11.1/mingw8.1_64/src/qtbase/src/corelib/global/qglobal.cpp:3333:5: note: suggested alternative: '_wgetenv' _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ _wgetenv mingw32-make: *** [Makefile:360: qglobal.o] Error 1 I tried to find any clue online but seems that it is not very frequent. Any help would be highly appreciated. Thank you! Regards, Khuram Ali _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.lemanissier at gmail.com Tue Jul 31 15:04:55 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Tue, 31 Jul 2018 15:04:55 +0200 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: Please, don't introduce another type alias. It would loose the advantage of static analysis like http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development < development at qt-project.org> a écrit : > 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. > > * Even if we consider talking about the GSL too much of a "distraction" > in the docs, we can simply add our own qOwner type alias, with identical > semantics, and document what it does and what it means in signatures. > > * 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. At least, it's one more safeguard against > adding functions that take/return pointers and don't clearly document > the ownership. > > > 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 :-( > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53 <04%2090%2084%2008%2053>, > http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Tue Jul 31 15:16:13 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 31 Jul 2018 15:16:13 +0200 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <164f06e128a-c86-6547@webjas-vae032.srv.aolmail.net> References: <164f06cf162-c8b-1a261@webjas-vab007.srv.aolmail.net> <164f06e128a-c86-6547@webjas-vae032.srv.aolmail.net> Message-ID: <20180731131612.GA23101@nubble.lan> On Tue, Jul 31, 2018 at 09:01:43AM -0400, Khuram Ali via Development wrote: > with correct subject line. > http://linux.sgms-centre.com/misc/netiquette.php#threading From giuseppe.dangelo at kdab.com Tue Jul 31 15:20:01 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 31 Jul 2018 15:20:01 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> Message-ID: <30b9c3c6-bb45-ac43-3b2a-edbb76a3d9f1@kdab.com> On 31/07/18 14:58, Edward Welbourne wrote: > I can believe static-built apps are common; and I guess apps using them > would need to make source changes in order to switch to their namespaced > form, or override the default of them being namespaced. What other > problem(s) had you in mind ? Exactly this problem: changing the default to a namespaced build would require source changes (*) in most applications that had been using static builds of Qt without namespaces. And this includes the applications affected by the bug that started this thread, so for them the solution won't just be "use this new version of Qt", it's going to be "use this new version of Qt AND change your source". So, it's a matter to decide whether such namespacing should be opt-in (like today) or opt-out (if you get errors when you upgrade Qt and you don't want to fix your code, pass options to configure to disable the namespace). (*) Sure, the changes are probably trivial (considering that would Qt also by default add a `using namespace QtNamespace` in all its headers), but it's still a SiC. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From khuram.ali at aim.com Tue Jul 31 15:21:41 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 09:21:41 -0400 Subject: [Development] Issue while compiling with MinGw_64 Message-ID: <164f08055e2-c8b-67c5@webjas-vac084.srv.aolmail.net> Dear All, I am new to Qt and trying to build it from source using MinGw_64. However, i am getting an error as below, qtbase/src/corelib/global/qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ C:/Qt/5.11.1/mingw8.1_64/src/qtbase/src/corelib/global/qglobal.cpp:3333:5: note: suggested alternative: '_wgetenv' _wgetenv_s(&requiredSize, 0, 0, wname.data()); ^~~~~~~~~~ _wgetenv mingw32-make: *** [Makefile:360: qglobal.o] Error 1 I tried to find any clue online but seems that it is not very frequent. Any help would be highly appreciated. Thank you! Regards, Khuram Ali Note: Thank you Oswald for your guidance about emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshegunov at gmail.com Tue Jul 31 15:58:06 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Tue, 31 Jul 2018 16:58:06 +0300 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote: > Hi, > > I'm wondering how we can avoid symbol clashes in static Qt libs + user > code. > > a) Prefix all symbols with 'q', like we do for exported symbols. > > This requires some bigger patches. See e.g. https://codereview.qt-project. > org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase. > Isn't introducing a private namespace for that purpose an option? I think it'd fare better than renaming the symbols, and in the end that's the whole reason for having them in the language, right? Granted there should be an using clause at the top of the sources that use those private methods and explicit scoping for public headers (if any), but that should solve the problem I believe. Also patching it up should be relatively straightforward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tor.arne.Vestbo at qt.io Tue Jul 31 16:01:37 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Tue, 31 Jul 2018 14:01:37 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: > On 31 Jul 2018, at 15:58, Konstantin Shegunov wrote: > > On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote: > Hi, > > I'm wondering how we can avoid symbol clashes in static Qt libs + user code. > > a) Prefix all symbols with 'q', like we do for exported symbols. > > This requires some bigger patches. See e.g. https://codereview.qt-project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in qtbase. > > Isn't introducing a private namespace for that purpose an option? > I think it'd fare better than renaming the symbols, and in the end that's the whole reason for having them in the language, right? > Granted there should be an using clause at the top of the sources that use those private methods and explicit scoping for public headers (if any), but that should solve the problem I believe. Also patching it up should be relatively straightforward. That seems preferable to the variable renaming, yes. Tor Arne > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Jul 31 16:01:50 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 31 Jul 2018 14:01:50 +0000 Subject: [Development] Merge and Integration status report - 2018.07.04 In-Reply-To: <0674DC67-961C-48F3-ADBE-137115C14FD2@qt.io> References: <0674DC67-961C-48F3-ADBE-137115C14FD2@qt.io> Message-ID: While Liang has been away (he'll be back later this week): Merges (various module owners; and I helped out a bit): * qt5's last upmerge was 5.11->dev on July 12 * qtbase 5.11->dev, https://codereview.qt-project.org/233803 took 20 tries, but we got there in the end (July 17); we've not had another integrate since, but one is in Coin as I write * four other modules merged yesterday. * we also got a 5.9->5.11 upmerge for qttranslations, today; that brought to light that 5.11 needed MODULE_VERSION updates in all modules. * 32 modules had 5.11->dev successful merges today (22 of them within an hour, 10:26 to 11:25), dealing with MODULE_VERSION conflicts * full history (and on-going activity) at: https://codereview.qt-project.org/#/q/owner:"Qt+Forward+Merge+Bot",n,z Integrations (Simon mostly): * qt5 dev, https://codereview.qt-project.org/233675 went through on July/18th followed by daily success all through last week but this week is blocked by QTBUG-69704, see https://codereview.qt-project.org/235389 * qt5 5.11 is healthy, also roughly daily, most recently today * full history (and on-going activity) at: https://codereview.qt-project.org/#/q/owner:"Qt+Submodule+Update+Bot",n,z Eddy. From thiago.macieira at intel.com Tue Jul 31 16:41:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 07:41:15 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <5cb814c3-3429-92e5-eff6-2c913a1fe402@gmail.com> References: <5cb814c3-3429-92e5-eff6-2c913a1fe402@gmail.com> Message-ID: <2817439.2nYDco8JQh@tjmaciei-mobl1> On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote: > As for me, is it prefferable variant will be *QBS* (it is best from the > best). > > I'm do not like nor CMake, nor QMake, nor Autotools, nor something else. I would say the only two options in the running are qbs and CMake. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jul 31 16:52:37 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 07:52:37 -0700 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: <6186155.Plj3Ov170P@tjmaciei-mobl1> On Tuesday, 31 July 2018 04:43:36 PDT Kai Koehne wrote: > Note also that the logging categories are by far not the only non-prefixed > symbols that might cause clashes when statically linking. See > https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that > don't contain a q or Q , for a static Qt build of mine. 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. Your list also includes third-party libraries (doubleconversion, Harfbuzz, xkb). Can you check whether those symbols come from a Qt library or from that particular library that was linked into your application? That is, were the sources from that library added to the Qt's .a file? Or was there a .a for that library? > I can think of 3 approaches to tackle this: > > a) Prefix all symbols with 'q', like we do for exported symbols. > > This requires some bigger patches. See e.g. > https://codereview.qt-project.org/#/c/235631/ for renaming all logging > categories to 'qlc*' in qtbase. Ugly, but good idea. Another trick, which is not a one-line patch, is: namespace QtLogging { Q_CATEGORY_LOGGING(whatever) } using QtLogging::whatever; > b) Advise people to always configure static Qt in a namespace > (-qtnamespace). Recommendation, but it's not too bad today anyway. People have been using static builds for over two decades. So a recommendation I agree with. > This should fix it for symbols at least in our own code. Maybe we should > make it even the default for static builds in Qt 6? That I don't. > c) Look into tricks like 'objcopy --localize-hidden' to hide symbols. > > This would probably require some major hackery in the build system. No idea > whether this is supported also on other platforms, and how hard it would be > to pull it off. I'm not volunteering We don't need it in all platforms, but this post-processing step isn't a bad idea where it is present. Good idea. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jul 31 16:57:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 07:57:39 -0700 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: <4435284.KOGfq56aWA@tjmaciei-mobl1> 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 From thiago.macieira at intel.com Tue Jul 31 17:00:08 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 08:00:08 -0700 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <164f08055e2-c8b-67c5@webjas-vac084.srv.aolmail.net> References: <164f08055e2-c8b-67c5@webjas-vac084.srv.aolmail.net> Message-ID: <1551478.QLfZp6Ee3P@tjmaciei-mobl1> On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From eric.lemanissier at gmail.com Tue Jul 31 17:12:09 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Tue, 31 Jul 2018 17:12:09 +0200 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <1551478.QLfZp6Ee3P@tjmaciei-mobl1> References: <164f08055e2-c8b-67c5@webjas-vac084.srv.aolmail.net> <1551478.QLfZp6Ee3P@tjmaciei-mobl1> Message-ID: it looks like https://bugreports.qt.io/browse/QTBUG-67443 what version of mingw are you using ? Le mar. 31 juil. 2018 à 17:00, Thiago Macieira a écrit : > On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope > > The problem is your MinGW headers and CRT. You need one that has > _wgetenv_s. > > In the MinGW-w64 headers I have, they exist. So check if you should erase > your > MinGW installation and install another. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuram.ali at aim.com Tue Jul 31 17:19:02 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 11:19:02 -0400 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <1551478.QLfZp6Ee3P@tjmaciei-mobl1> Message-ID: <164f0ebc91a-c90-1835e@webjas-vab028.srv.aolmail.net> Thanks Thiago! Yes you are right. i am using nuwen MinGW distribution and it doesn't contain _wgetenv_s. Regards, Khuram Ali -----Original Message----- From: Thiago Macieira To: development Sent: Tue, Jul 31, 2018 5:00 pm Subject: Re: [Development] Issue while compiling with MinGw_64 On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuram.ali at aim.com Tue Jul 31 17:31:28 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 11:31:28 -0400 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: Message-ID: <164f0f72c3b-c8c-1b0fd@webjas-vab157.srv.aolmail.net> That is true. I am using newen distro. Regards, Khuram Ali -----Original Message----- From: Eric Lemanisser To: Thiago Macieira Cc: development Sent: Tue, Jul 31, 2018 5:12 pm Subject: Re: [Development] Issue while compiling with MinGw_64 it looks like https://bugreports.qt.io/browse/QTBUG-67443 what version of mingw are you using ? Le mar. 31 juil. 2018 à 17:00, Thiago Macieira a écrit : On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From KoAhnig at hotmail.de Tue Jul 31 17:44:45 2018 From: KoAhnig at hotmail.de (H-J Euler) Date: Tue, 31 Jul 2018 15:44:45 +0000 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <164f0ebc91a-c90-1835e@webjas-vab028.srv.aolmail.net> References: <1551478.QLfZp6Ee3P@tjmaciei-mobl1> <164f0ebc91a-c90-1835e@webjas-vab028.srv.aolmail.net> Message-ID: End of last year I experimented with different “MinGW 64 bit compilers” for compilation of boost and Qt libs. I succeeded using MinGW 7.2.0 x86_64-7.2.0-posix-seh-rt_v5-rev1 from http://mingw-w64.org on Qt 5.9.3. The most challenging part was the MinGW interface for finding and installing the right combination for the actual 64bit compiler. For an unexperienced user a nightmare IMHO. Hope this helps. Best regards Von: Development Im Auftrag von Khuram Ali via Development Gesendet: Dienstag, 31. Juli 2018 17:19 An: thiago.macieira at intel.com; development at qt-project.org Betreff: Re: [Development] Issue while compiling with MinGw_64 Thanks Thiago! Yes you are right. i am using nuwen MinGW distribution and it doesn't contain _wgetenv_s. Regards, Khuram Ali -----Original Message----- From: Thiago Macieira > To: development > Sent: Tue, Jul 31, 2018 5:00 pm Subject: Re: [Development] Issue while compiling with MinGw_64 On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuram.ali at aim.com Tue Jul 31 17:47:47 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 11:47:47 -0400 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: <164f0f72c3b-c8c-1b0fd@webjas-vab157.srv.aolmail.net> Message-ID: <164f1061d1c-c8d-1b460@webjas-vad102.srv.aolmail.net> With fix of philippe dunski, build seems to working. Thank you very much for help! Regards, Khuram Ali -----Original Message----- From: Khuram Ali via Development To: eric.lemanissier ; thiago.macieira Cc: development Sent: Tue, Jul 31, 2018 5:31 pm Subject: Re: [Development] Issue while compiling with MinGw_64 That is true. I am using newen distro. Regards, Khuram Ali -----Original Message----- From: Eric Lemanisser To: Thiago Macieira Cc: development Sent: Tue, Jul 31, 2018 5:12 pm Subject: Re: [Development] Issue while compiling with MinGw_64 it looks like https://bugreports.qt.io/browse/QTBUG-67443 what version of mingw are you using ? Le mar. 31 juil. 2018 à 17:00, Thiago Macieira a écrit : On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuram.ali at aim.com Tue Jul 31 17:52:00 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Tue, 31 Jul 2018 11:52:00 -0400 Subject: [Development] Issue while compiling with MinGw_64 In-Reply-To: Message-ID: <164f109fc02-c8b-788c@webjas-vae122.srv.aolmail.net> Thank you! but it would be far easier if the fix from philippe dunski could be added in official Qt distribution. It would be compatible with latest MinGW distribution. Regards, Khuram Ali -----Original Message----- From: H-J Euler To: Khuram Ali ; development Sent: Tue, Jul 31, 2018 5:44 pm Subject: AW: [Development] Issue while compiling with MinGw_64 End of last year I experimented with different “MinGW 64 bit compilers” for compilation of boost and Qt libs. I succeeded using MinGW 7.2.0 x86_64-7.2.0-posix-seh-rt_v5-rev1 from http://mingw-w64.org on Qt 5.9.3. The most challenging part was the MinGW interface for finding and installing the right combination for the actual 64bit compiler. For an unexperienced user a nightmare IMHO. Hope this helps. Best regards Von: Development Im Auftrag von Khuram Ali via Development Gesendet: Dienstag, 31. Juli 2018 17:19 An: thiago.macieira at intel.com; development at qt-project.org Betreff: Re: [Development] Issue while compiling with MinGw_64 Thanks Thiago! Yes you are right. i am using nuwen MinGW distribution and it doesn't contain _wgetenv_s. Regards, Khuram Ali -----Original Message----- From: Thiago Macieira To: development Sent: Tue, Jul 31, 2018 5:00 pm Subject: Re: [Development] Issue while compiling with MinGw_64 On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote: > qglobal.cpp:3333:5: error: '_wgetenv_s' was not declared in this scope The problem is your MinGW headers and CRT. You need one that has _wgetenv_s. In the MinGW-w64 headers I have, they exist. So check if you should erase your MinGW installation and install another. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Tue Jul 31 18:35:42 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 31 Jul 2018 13:35:42 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2817439.2nYDco8JQh@tjmaciei-mobl1> References: <5cb814c3-3429-92e5-eff6-2c913a1fe402@gmail.com> <2817439.2nYDco8JQh@tjmaciei-mobl1> Message-ID: <3519322.vjceWHmQeL@tonks> El martes, 31 de julio de 2018 11:41:15 -03 Thiago Macieira escribió: > On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote: > > As for me, is it prefferable variant will be *QBS* (it is best from the > > best). > > > > I'm do not like nor CMake, nor QMake, nor Autotools, nor something else. > > I would say the only two options in the running are qbs and CMake. Just for curiosity I checked qbs' reverse dependencies (packages that require qbs installed in order to be built) in Debian. We currently only have two of them: qtcreator and dewalls (a library). -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From jeanmichael.celerier at gmail.com Tue Jul 31 18:58:11 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 31 Jul 2018 18:58:11 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2817439.2nYDco8JQh@tjmaciei-mobl1> References: <5cb814c3-3429-92e5-eff6-2c913a1fe402@gmail.com> <2817439.2nYDco8JQh@tjmaciei-mobl1> Message-ID: > I would say the only two options in the running are qbs and CMake. About this, I don't know if C++ community acceptance is a criterion, but : https://github.com/search?q=cmake https://github.com/search?q=qbs On Tue, Jul 31, 2018 at 4:41 PM, Thiago Macieira wrote: > On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote: > > As for me, is it prefferable variant will be *QBS* (it is best from the > > best). > > > > I'm do not like nor CMake, nor QMake, nor Autotools, nor something else. > > I would say the only two options in the running are qbs and CMake. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jul 31 19:49:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 10:49:49 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <3519322.vjceWHmQeL@tonks> References: <2817439.2nYDco8JQh@tjmaciei-mobl1> <3519322.vjceWHmQeL@tonks> Message-ID: <2647712.OyCeee2lpT@tjmaciei-mobl1> On Tuesday, 31 July 2018 09:35:42 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > > I would say the only two options in the running are qbs and CMake. > > Just for curiosity I checked qbs' reverse dependencies (packages that > require qbs installed in order to be built) in Debian. We currently only > have two of them: qtcreator and dewalls (a library). I know. That's why I am challenging the supporters of qbs to meet my requests in (2). To wit: a) Must be used by roughly a dozen packages in major distros. I'm not saying all of them have to have a dozen, not even that one of them has a dozen. But all of the ones listed above must have at least one and there must be a dozen distinct packages in total. b) At least one package must have been continuously packaged for two years. One for an RPM distro and one for a .deb distro. c) At least one package of comparable complexity to qtbase, packaged by the three of the six Linux distros I listed. I'm looking for: - compiling certain files with different compiler flags - several third-party dependencies, some required, others optional - lots of configure-time options - installing several different types of targets (binaries, libraries, plugins, arch-dependent files, arch-independent files, documentation, translations, etc.) - obeying distro-supplied options (compiler & linker flags, compiler selection [ccache, icecc, clang], debuginfo split, stripping, etc.) I know CMake meets these requirements, but it has other problems and the fact that it currently does not build Qt. On that front, qbs is ahead. But qbs has a shorter track record. Since we're not switching buildsystems in the next 2 years, there's time for the proponents of qbs to take actions to achieve those requirements above. In other words: get others to adopt the buildsystem before we switch Qt. Prove that it can support Qt. I know switching Qt would gain it a big critical mass, the same way that KDE switching to CMake in 2006 gave CMake an important boost [*]. But we're not switching Qt just yet, so if you're saying the tool is ready, get others to use it now. [*] I was there in Akademy 2005 when we decided to use Scons because CMake's language was too ugly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Tue Jul 31 20:15:50 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 31 Jul 2018 21:15:50 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2647712.OyCeee2lpT@tjmaciei-mobl1> References: <2817439.2nYDco8JQh@tjmaciei-mobl1> <3519322.vjceWHmQeL@tonks> <2647712.OyCeee2lpT@tjmaciei-mobl1> Message-ID: On 31 July 2018 at 20:49, Thiago Macieira wrote: > I know CMake meets these requirements, but it has other problems and the fact > that it currently does not build Qt. On that front, qbs is ahead. But qbs has > a shorter track record. Since we're not switching buildsystems in the next 2 > years, there's time for the proponents of qbs to take actions to achieve those > requirements above. > > In other words: get others to adopt the buildsystem before we switch Qt. Prove > that it can support Qt. > > I know switching Qt would gain it a big critical mass, the same way that KDE > switching to CMake in 2006 gave CMake an important boost [*]. But we're not > switching Qt just yet, so if you're saying the tool is ready, get others to > use it now. This provoked a thought in me, a way to make qbs worth all its effort: make debugging a build so staggeringly ridiculously good that it becomes attractive to use it. I don't know what debugging builds done with python-based build systems is like, but debugging make-based builds is rather horrible. From abbapoh at gmail.com Tue Jul 31 20:35:23 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 31 Jul 2018 21:35:23 +0300 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: I prefer the solution from the thread "unique_ptr and Qt" about using smart pointers for transferring ownership explicitly. We can use std::observer_ptr from c++20 to indicate the places that do not take ownership. I think, using gsl::owner is a wrong way of doing things, it's the way that can be source and (maybe) binary compatible, but that's a workaround, not a solution. However, the solution can require too much work to do. Иван Комиссаров > 31 июля 2018 г., в 16:04, Eric Lemanisser написал(а): > > Please, don't introduce another type alias. It would loose the advantage of static analysis like http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html > >> Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development a écrit : >> 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. >> >> * Even if we consider talking about the GSL too much of a "distraction" >> in the docs, we can simply add our own qOwner type alias, with identical >> semantics, and document what it does and what it means in signatures. >> >> * 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. At least, it's one more safeguard against >> adding functions that take/return pointers and don't clearly document >> the ownership. >> >> >> 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 :-( >> >> >> My 2 c, >> -- >> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >> KDAB (France) S.A.S., a KDAB Group company >> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com >> KDAB - The Qt, C++ and OpenGL Experts >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Jul 31 20:39:55 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 31 Jul 2018 21:39:55 +0300 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: <10679091533062395@sas1-d627dcb07a0e.qloud-c.yandex.net> 31.07.2018, 21:35, "Иван Комиссаров" : > I prefer the solution from the thread "unique_ptr and Qt" about using smart pointers for transferring ownership explicitly. We can use std::observer_ptr from c++20 to indicate the places that do not take ownership. > I think, using gsl::owner is a wrong way of doing things, it's the way that can be source and (maybe) binary compatible, but that's a workaround, not a solution. It's binary compatible, because owner = T. It's not a solution, just annotation for people static analyzers (like e.g. "emit" keyword in Qt) > However, the solution can require too much work to do. It also requires changic public APIs, which can only be done in Qt 6. > > Иван Комиссаров > > 31 июля 2018 г., в 16:04, Eric Lemanisser написал(а): > >> Please, don't introduce another type alias. It would loose the advantage of static analysis like http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html >> >> Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development a écrit : >>> 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. >>> >>> * Even if we consider talking about the GSL too much of a "distraction" >>> in the docs, we can simply add our own qOwner type alias, with identical >>> semantics, and document what it does and what it means in signatures. >>> >>> * 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. At least, it's one more safeguard against >>> adding functions that take/return pointers and don't clearly document >>> the ownership. >>> >>> 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 :-( >>> >>> My 2 c, >>> -- >>> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >>> KDAB (France) S.A.S., a KDAB Group company >>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com >>> KDAB - The Qt, C++ and OpenGL Experts >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From thiago.macieira at intel.com Tue Jul 31 20:40:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 11:40:32 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <2647712.OyCeee2lpT@tjmaciei-mobl1> Message-ID: <2204022.e0gc6Zjjm5@tjmaciei-mobl1> On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote: > This provoked a thought in me, a way to make qbs worth all its effort: > make debugging > a build so staggeringly ridiculously good that it becomes attractive > to use it. I don't know > what debugging builds done with python-based build systems is like, > but debugging make-based > builds is rather horrible. Aye. Debugging qmake builds are actually pretty easy, if you know -d and -d -d exist. You can easily follow the decisions it made. You'll get to a few corner cases where things that should be lists aren't or vice-versa, or quirks of the language where $$ is suppressed, etc. But most of the time you don't need that. (I'm not talking about debugging the tool itself) Debugging cmake builds aren't that easy. It writes a lot of logs, but sometimes magic happens. If the magic doesn't go your way, you're lost. Compared to qmake, the barrier of where the magic happens is lower, meaning that it happens more often than it should. Debugging Makefiles are a PITA. THAT was libvpx's buildsystem and that is what prompted me to post this thread. Debugging make using the -d option is a last resort and is still not completely sufficient, since it shows process starts but not the variable evaluations. Finally, debugging autoconf is actually not that difficult either. Because it's a shell script, there are tons of techniques you can use. And it creates a fairly comprehensive log file, similar to qmake's -d output. Debugging automake is a different story, but it's a very limited tool. And don't try to debug libtool (you can live an entire lifetime using it and never debug it). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From scott at towel42.com Tue Jul 31 20:43:49 2018 From: scott at towel42.com (Scott Bloom) Date: Tue, 31 Jul 2018 18:43:49 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2204022.e0gc6Zjjm5@tjmaciei-mobl1> References: <2647712.OyCeee2lpT@tjmaciei-mobl1> <2204022.e0gc6Zjjm5@tjmaciei-mobl1> Message-ID: -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: Tuesday, July 31, 2018 11:41 To: development at qt-project.org Subject: Re: [Development] Qt 6 buildsystem support requirements On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote: > This provoked a thought in me, a way to make qbs worth all its effort: > make debugging > a build so staggeringly ridiculously good that it becomes attractive > to use it. I don't know what debugging builds done with python-based > build systems is like, but debugging make-based builds is rather > horrible. Aye. Debugging qmake builds are actually pretty easy, if you know -d and -d -d exist. You can easily follow the decisions it made. You'll get to a few corner cases where things that should be lists aren't or vice-versa, or quirks of the language where $$ is suppressed, etc. But most of the time you don't need that. (I'm not talking about debugging the tool itself) Debugging cmake builds aren't that easy. It writes a lot of logs, but sometimes magic happens. If the magic doesn't go your way, you're lost. Compared to qmake, the barrier of where the magic happens is lower, meaning that it happens more often than it should. Debugging Makefiles are a PITA. THAT was libvpx's buildsystem and that is what prompted me to post this thread. Debugging make using the -d option is a last resort and is still not completely sufficient, since it shows process starts but not the variable evaluations. Finally, debugging autoconf is actually not that difficult either. Because it's a shell script, there are tons of techniques you can use. And it creates a fairly comprehensive log file, similar to qmake's -d output. Debugging automake is a different story, but it's a very limited tool. And don't try to debug libtool (you can live an entire lifetime using it and never debug it). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center =============== Just a note.. for CMake, I find the -debug-output -trace and -trace-expand as useful as the -d and -d -d . One other thing I use all the time for dependency analysis, is the -graphviz switch. Scott From abbapoh at gmail.com Tue Jul 31 20:52:11 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 31 Jul 2018 21:52:11 +0300 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: <10679091533062395@sas1-d627dcb07a0e.qloud-c.yandex.net> References: <3843684.v7fED68053@tjmaciei-mobl1> <10679091533062395@sas1-d627dcb07a0e.qloud-c.yandex.net> Message-ID: Иван Комиссаров > 31 июля 2018 г., в 21:39, Konstantin Tokarev написал(а): > > > > 31.07.2018, 21:35, "Иван Комиссаров" : >> I prefer the solution from the thread "unique_ptr and Qt" about using smart pointers for transferring ownership explicitly. We can use std::observer_ptr from c++20 to indicate the places that do not take ownership. >> I think, using gsl::owner is a wrong way of doing things, it's the way that can be source and (maybe) binary compatible, but that's a workaround, not a solution. > > It's binary compatible, because owner = T. It's not a solution, just annotation for people static analyzers (like e.g. "emit" keyword in Qt) > >> However, the solution can require too much work to do. > > It also requires changic public APIs, which can only be done in Qt 6. > That's why we discussing that right now, not after the qt6 will be released:) >> >> Иван Комиссаров >> >>> 31 июля 2018 г., в 16:04, Eric Lemanisser написал(а): >>> >>> Please, don't introduce another type alias. It would loose the advantage of static analysis like http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html >>> >>>> Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development a écrit : >>>> 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. >>>> >>>> * Even if we consider talking about the GSL too much of a "distraction" >>>> in the docs, we can simply add our own qOwner type alias, with identical >>>> semantics, and document what it does and what it means in signatures. >>>> >>>> * 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. At least, it's one more safeguard against >>>> adding functions that take/return pointers and don't clearly document >>>> the ownership. >>>> >>>> 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 :-( >>>> >>>> My 2 c, >>>> -- >>>> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >>>> KDAB (France) S.A.S., a KDAB Group company >>>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com >>>> KDAB - The Qt, C++ and OpenGL Experts >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> , >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > -- > Regards, > Konstantin From thiago.macieira at intel.com Tue Jul 31 21:33:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 31 Jul 2018 12:33:41 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <2204022.e0gc6Zjjm5@tjmaciei-mobl1> Message-ID: <2070633.fLKvYRvhaS@tjmaciei-mobl1> On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote: > Just a note.. for CMake, I find the -debug-output -trace and -trace-expand > as useful as the -d and -d -d . > > One other thing I use all the time for dependency analysis, is the -graphviz > switch. Thanks, noted. I didn't know about those. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Tue Jul 31 21:43:37 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 31 Jul 2018 22:43:37 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2070633.fLKvYRvhaS@tjmaciei-mobl1> References: <2204022.e0gc6Zjjm5@tjmaciei-mobl1> <2070633.fLKvYRvhaS@tjmaciei-mobl1> Message-ID: On 31 July 2018 at 22:33, Thiago Macieira wrote: > On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote: >> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand >> as useful as the -d and -d -d . >> >> One other thing I use all the time for dependency analysis, is the -graphviz >> switch. > > Thanks, noted. I didn't know about those. Trace-debugging is nice, but I'm actually envisioning launching Creator, opening a build with it as a build-project (instead of opening it as a project that builds what the build builds :P) and stepping through the build.