Re: [Development] Build system for Qt 6
On 12/16/2018 08:05 PM, Thiago Macieira wrote: On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote: As I say it's "ok" for developers but not for packagers. Which one is ok for packagers? From packaging standpoint, autotools are clearly the best. But I would say cmake is ok for 2nd place. qmake is also nice, but that's what we want to get rid of. In general, the rule would be: any system that is widely used is superior to any system that is not so widely used. If you have some magic buildsystem that no one is using, it will sooner or later bite you in the butt. The lack of maintenance and development and simply users of the build system will result in large technical debt as compared to more popular build systems. And eventually one will have to scrap it. I'll just give two examples here. Boost.Build - was to be the "simplest" build system... and now no one wants to use it, even the Boost project. It's the opposite of simple to understand. Another example is Gyp. It's used by Node and V8. It's been abandoned by Google and it's using python2 and there is little motivation to migrate it to Python3 - something will have to give here soon. And in both these cases using cmake would have resulted in easier maintenance. Actually, Boost is slowly migrating to cmake. So yes, just use cmake knowing that you will find some problems. But at least you no longer have to maintain the build tool itself. - Adam ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Documentation proposal: Remove recommended reading list of 20-year-old books
On Mon, Aug 31, 2015 at 08:18:59PM +0300, Berkay Elbir wrote: >Yeah, replacing would be better than just removing... Almost every modern C++ (and other programming language) book deals with basics of threads and concurrency. Concurrent programming is standard for a decade now. C++ standard now has a notion of multithreads. In light of this, I believe a simple statement about getting a moden C++ book is enough. If a link is desired, how about "C++ Concurrency in Action: Practical Multithreading" by Williams. http://www.amazon.com/dp/1933988770 NOTE: I haven't read this book, but from TOC it seems to cover most important things about threads. - Adam -- Adam Majer ad...@zombino.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New git mirror - http://code.qt.io
On Tue, Feb 24, 2015 at 12:54:48PM +, Hirvonen Olli wrote: Hi, We have installed a new read-only git mirror under qt.io domain (http://code.qt.io). The purpose of this git mirror is to act as a authoritative git mirror for Qt sources, and we plan to change links on our own web pages to it where applicable. The new service does not have impact to existing mirrors such as GitHub (https://github.com/qtproject) and Gitorious (http://qt.gitorious.org/), but we want to have our own mirror under qt.io domain as well. This is nice, but there is something else that could be even more beneficial. If you guys could sign tags that would be even more authoritative than a dedicated git. For example, in QtCreator's repository, $ git tag -v v3.3.1 object 567c6eb8759436a94835d06cf209956229265220 type commit tag v3.3.1 tagger Eike Ziller eike.zil...@theqtcompany.com 1424783381 +0100 Qt Creator v3.3.1 error: no signature found error: could not verify the tag 'v3.3.1' A signed tag automatically verifies the entire history as being authentic (up to the tag). - Adam PS. GPG signed releases would also be nice in addition to simple hash checksums. For example, one file with ALL hashes that is then signed would verify these hashes (and all releases) as authentic. -- Adam Majer ad...@zombino.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mime database size
On Mon, Feb 23, 2015 at 07:48:37AM +0100, Mathias Hasselmann wrote: Am 17.02.2015 um 14:36 schrieb Cristian Adam: One could rewrite this small utility into Qt and then it would be available everywhere. Somehow I thought that one of the big benefits of free software and open source is, that you _don't_ have to rewrite each and every simple tool. Obviously I've missed something. By rewrite, he meant *port to*. So, you don't have to rewrite anything, just port it to the API that is available on a given platform. By porting it to Qt, then it would be automatically available everywhere that Qt is available. If the utility was not free open source, you would have to rewrite the entire utility from scratch instead of just porting it. - Adam -- Adam Majer ad...@zombino.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
