Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))
On Fri, 23 Aug 2019, 17:11 Thiago Macieira, wrote: > On Friday, 23 August 2019 00:12:50 PDT Roland Winklmeier wrote: > > Just for your awareness: There is an old bug related to thread_local in > > MinGW which afaik was never fixed. It compiles correctly, but every > > executable crashes during shutdown. Not sure if this relevant in this > case, > > just mentioning it: > > https://github.com/msys2/MINGW-packages/issues/2519 > > The description of the bug says "winpthreads", which means it's not MinGW, > it's Cygwin/MSYS2. This is completely incorrect. Thiago I would expect better from you. > libgcc on pure MinGW doesn't use winpthreads, it uses Win32. > > Anyway, let's apply Q_THREAD_LOCAL. If that causes GCC-built MinGW > applications to crash on exit, then we stop using GCC and switch to Clang. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
On Thu, 22 Aug 2019, 00:01 Thiago Macieira, wrote: > On Wednesday, 21 August 2019 13:39:55 PDT Kai Pastor, DG0YT wrote: > > Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2. > > For building Windows applications, you use a MinGW subsystem, and there > > is no msys-2.0.dll. > > That's just MinGW, albeit the build from MSYS2. If that's what was meant, > I'm > all for it. After the upgrade I've just run, I have GCC 9.2, which is > great. > It is not MinGW,v it is a mingw-w64 based, developer focused build system. The POSIX software we provide exists only to support this goal. To be clear we refuse to add packages to the msys2 subsystem package set if they are not either in support of building native software or in support of making life easier for developers of the same. We (along with conda-forge though both independently) are also leading the charge to get clang into a working state on windows. You can see the patches we apply and it recipe at https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-qt5 I find it depressing quite frankly that you know so little about it given your position. MSYS2 grew out of the old QtBuilds and mingw-builds projects (same initial developers). We also decided from the beginning to use dw2 exceptions based on your recommendation. This was many years ago. Try it you might like it. The initial runtime update thing is unfortunate, we link our pacman as statically as we can but it's not possible to statically link the runtime. MSYS2 has also been adopted as the upstream env for Git for Windows so mostly everyone using git on windows is running MSYS2 software even if they do not know it. Also most of the old game system and computer emulation world are based on MSYS2. I could do on but I will not. It is the greatest gift to software packaging on windows yet to be created IMNSHO (I am very proud of our success here) though for scientific computing conda-forge is often more appropriate. We also produce builds - MSVC based, but considering clang as the compiler in the future - of qt at conda-forge (I help maintain the recipes). Those patches can be found at https://github.com/conda-forge/qt-feedstock/tree/master/recipe I would love to upstream what I can from these endeavors but my time is short (in a very real, serious sense). I'd love to work closely with a few core developers to unload this patch burden from both before I cannot anymore. > > But I had understood the proposal as linking to MSYS2 libraries. > You should always assume that native software is being discussed when people mention MSYS2 in this way. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On Dec 18, 2018 12:33 PM, "Matthew Woehlke" wrote: On 15/12/2018 15.49, Ray Donnelly wrote: > Do you know for example that cmake will find dlls in C:\Windows\System32, Uh... yeah? I think most people *expect* that... Would you also rather CMake didn't look in /usr/lib[64] on Linux systems? *Why*? Because you are then building software that (possibly unbeknownst to you unless you are an expert in the arcane ways of cakeh, cannot work without the presence of any such found DSO (or ABI and SONAME compatible DSO in the RPATH). Compilers will happily tell you what implicit folders they will look in on Linux and cmake does query that (it does not pay the same respect to static linkers even though I sent in a patch for exactly that) but this isn't of any help on Windows. Explicit is always better than implicit for this kind of thing and hermeticity is important as is reproducability. Take a simple example of a build that found your own zlib.dll yesterday but no longer does today, because you installed some random 3rd party software that happened to put zlib.dll in System32 in the meantime. This particular feature bites all the time. As I said 'ok' for developers but not for packagers. > find_package is still inscrutable, and it's for sure the cause of > most issues we see as software packagers). Well, yeah, find modules are... not ideal. Modern software should be providing package configuration files with exported targets. If we switched to CPS¹ (SHTDI!), that would be even better (mostly-human-readable files that don't use CMake syntax). (¹ https://mwoehlke.github.io/cps/) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt > > Here in Fedora, we actually *want* CMake to find system libraries. The > > situation on Windows is of course different, and third-party packages > for > > GNU/Linux may or may not want to use the system libraries, but our > > distribution packages definitely want to use them. > > ... and if you cross-compile, you definetly don't want to your build system > to stick its nose into your system librararies on any platform. > > Therefore I see build automation and packaging as orthogonal processes. IMO > it lowers the usage complexity and leaves more room for flexibility when > being kept separate. The package system would be responsible to resolve > dependencies and could produce files that the build automation system would > consume. I kind of like the idea behind Conan which does only package > management, dependency resolution and provides simple-enough generators for > all kinds of build automation system. > > The discussion about build systems reminds me a bit of a religious war. I > made my peace with CMake and use it only when being paid for. It allows me > to use the browser more often and to find obscure stuff on the internet. > It's an expensive tool. After work I want to get my stuff done with low > investment, hence I often use Qbs ;-) > That sounds like a very sensible approach Richard. > > Richard > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
The On Sun, Dec 16, 2018, 1:17 PM Thiago Macieira 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? > > In Clear Linux, we also have people who dislike CMake. They recommend only > Autoconf and Meson. > I agree with that. I also like qbs and wish it had seen more adoption so that people would be less nervous about it .. and that it was spun out from requiring qt (or any heavy dependencies) so it could be built much earlier in the stack. Still it hasn't and that's a shame. One thing I'll say in cmake's defence (not that it needs any from me, it seems to have taken over) is that I prefer it to bazel in most respects. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
I'll not going to do this for you, sorry. I also pointed out the lack of isolation from system libraries by default as a major problem. Take any complex project and try it. Basically very few will work on all generators. In particular ide generators cannot express complex build dependencies very well and any use of scripts will tend not to work unless you hardcore them for each one. I'm not in a position to investigate this. I just want build tools to get out of my way. I work in the Anaconda Distribution as a software packager and spend a significant amount of my working day battling cmake. As I say it's "ok" for developers but not for packagers. On Sun, Dec 16, 2018, 6:05 AM Alexander Neundorf Hi, > > On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote: > > On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf wrote: > > > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote: > > > > > Thus this investment would be at the expense of other things we’d > like > > > > > > to > > > > > > > do, like improving our IDE, working on rearchitecting and cleaning up > > > > our > > > > core frameworks for Qt 6 or the design tooling we are currently > > > > investing > > > > into. The Qt Company believes that those other investments are more > > > > important for the future of Qt than our choice of build tool. > > > > > > > > I don't understand. Will it not be a return on the investment when > > > > people > > > > use Qt "because their build tool is the best around" ? > > > > Project files are at the root of every project. There are all sorts > of > > > > > > good > > > > > > > IDEs around but ppl mostly are forced to use CMAKE which no one > seems to > > > > like. > > > > > > I do like it :-P > > > CMake can generate not only Makefiles and ninja files, but also project > > > files for > > > IDEs (Visual Studio, XCode, Eclipse). > > > With the addition of "server mode" 2 or 3 years ago or so now also a > tight > > > integration with IDEs is possible. I think QtCreator and/or KDevelop > make > > > use > > > of this. > > > So, when using cmake the developer is free to chose whether he wants to > > > use > > > simply an editor and make/ninja, or a full IDE. > > > > In my experience with cmake any non trivial implementation only tends to > > work with the generator(s) the developer tested against most recently. > > Which features are not working for which generators ? > As far as I know the ASM support may not really be working with the Visual > Studio generators. Is there more ? > IMO those are issues/bugs, and developers who want to use these generators > should put some effort into getting this fixed. > > Alex > > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote: > > > Thus this investment would be at the expense of other things we’d like > to > > > > do, like improving our IDE, working on rearchitecting and cleaning up our > > core frameworks for Qt 6 or the design tooling we are currently investing > > into. The Qt Company believes that those other investments are more > > important for the future of Qt than our choice of build tool. > > > > I don't understand. Will it not be a return on the investment when people > > use Qt "because their build tool is the best around" ? > > Project files are at the root of every project. There are all sorts of > good > > IDEs around but ppl mostly are forced to use CMAKE which no one seems to > > like. > > I do like it :-P > CMake can generate not only Makefiles and ninja files, but also project > files for > IDEs (Visual Studio, XCode, Eclipse). > With the addition of "server mode" 2 or 3 years ago or so now also a tight > integration with IDEs is possible. I think QtCreator and/or KDevelop make > use > of this. > So, when using cmake the developer is free to chose whether he wants to > use > simply an editor and make/ninja, or a full IDE. > In my experience with cmake any non trivial implementation only tends to work with the generator(s) the developer tested against most recently. Also even when more than one generator works on a given platform, the binaries produced will differ in many ways, some important, some not so important. This is a terrible situation. Other than that to achieve this multi generator goal, you end up with a lowest common denominator or features (or generators that cannot be used on a given project). I dislike meta-make systems. They work ok for software developers but for software packagers they tend to be very problematic. Do you know for example that cmake will find dlls in C:\Windows\System32, common libs like zlib often get put there and disabling this requires an explicit option to be passed (and discovering that this is what happens and how to prevent it were far from trivial - find_package is still inscrutable, and it's for sure the cause of most issues we see as software packagers). > Alex > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
Agreed, a brilliant bit of technology, such a shame to see it deprecated. On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: > > > Having had the pleasure to use QBS quite extensively (and successfully) in > the past, I would like to thank the QBS team and contributors for showing us > what a sane, modern build system could look like. > So long! > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: >> >> Hi all, >> >> As you will probably remember, there have been lively discussions around >> what kind of build tool to use for Qt 6 both during Qt Contributor Summits >> as well as on this mailing list. >> >> There has been a strong consent that we should move away from qmake as our >> build tool for Qt due to many shortcomings and the burden we have >> maintaining the system. >> >> Thiago wrote a set of relatively strict requirements for such a build tool >> in his mail in July. While some of the requirements had a bit of a Linux >> specific background, they have been a good basis. >> >> There have been rather lively discussions around alternatives, but most >> focused around two possible choices for us: Qbs and cmake. >> >> Qbs is something that has been developed almost exclusively by The Qt >> Company. As such, TQtC had to also look at it from a business perspective >> and how it fits into the larger picture of making Qt successful. To make a >> long story short, while Qbs is pretty cool and interesting technology, it >> doesn’t really help us expand the Qt ecosystem and usage. >> >> To make Qbs really successful would require a rather large effort and >> investment in promoting it towards the larger C++ ecosystem as a new build >> tool. At the same time it has to be an open source product to stand any >> chance in the market. Together this makes it challenging for TQtC to see how >> to recover that investment. Thus this investment would be at the expense of >> other things we’d like to do, like improving our IDE, working on >> rearchitecting and cleaning up our core frameworks for Qt 6 or the design >> tooling we are currently investing into. The Qt Company believes that those >> other investments are more important for the future of Qt than our choice of >> build tool. >> >> As such, we were left with the question on whether we need Qbs as the build >> system for Qt 6 or whether cmake (as the other alternative) would be up to >> the task. >> >> Given that background, we’ve done some more research on using both Qbs and >> cmake to build Qt. Both projects did give us good results but we were >> actually surprised on how far we got with cmake in a rather limited period >> of time. >> >> In addition, cmake has the advantage of being very widely used in the C++ >> ecosystem (amongst many others by KDE), has a very wide support in many IDEs >> and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge >> about the build system available in the ecosystem. Using it with Qt 6 would >> also mean that we can focus our support on two build systems for our users >> (qmake and cmake) and we would not have to add a third one to the mix. >> >> Given that we are confident we can build Qt 6 with cmake, I believe that it >> makes most sense to follow down that route. In case you’re interested, you >> can have a look at the cmake prototype code for qtbase on Gerrit in the >> wip/cmake branch. Please also let us know if you’re interested in helping >> with the effort of porting Qt’s build system over to cmake. >> >> We have been developing Qbs over the last years, and as such are committed >> to it for some more time. We are planning on another feature release in the >> first quarter of next year and will support it in Qt Creator for at least >> another year. Qbs is open source and if someone wants to take over and >> develop it further let us know as well. I’d also like to use this place to >> thank Christian and Jörg for all their great work on Qbs (and of course >> also anybody else who contributed to it). >> >> Cheers, >> Lars >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC 2017 15.8 upgrade
On Wed, Aug 15, 2018 at 5:18 PM, Thiago Macieira wrote: > On Wednesday, 15 August 2018 09:10:36 PDT Ray Donnelly wrote: >> Hi Thiago, >> >> Do you know what sort of state Qt is in w.r.t. VS 2017 15.8? The >> Anaconda Distribution team is considering whether to update to it and >> this would be great to know. > > It should just work. Obviously, please give us a bit more than 24 hours since > the compiler release to know more. > Sure thing, thanks. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC 2017 15.8 upgrade
Hi Thiago, Do you know what sort of state Qt is in w.r.t. VS 2017 15.8? The Anaconda Distribution team is considering whether to update to it and this would be great to know. On Wed, Aug 15, 2018 at 4:58 PM, Thiago Macieira wrote: > If you upgraded MSVC 2017 to 15.8 yesterday and you try to build qtbase, > you'll get a build error. This is fixed, but you need to make sure you erase > .qmake.stash files everywhere, since they contain the cached version of the > compiler. > > And since neither nmake nor jom update Makefiles on their own, erase them all > too. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 buildsystem support requirements
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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 buildsystem support requirements
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 &
Re: [Development] Qt 6 buildsystem support requirements
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.celer...@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.celer...@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@qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 buildsystem support requirements
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.celer...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 答复: Qt static compiler error
On Tue, Oct 27, 2015 at 3:09 PM, Ray Donnelly wrote: > On Tue, Oct 27, 2015 at 2:48 PM, Matthew Woehlke via Development > wrote: >> (Apologies for reposting information, but my other message is stuck >> somewhere in the moderation queue...) >> >> On 2015-10-26 22:58, Thiago Macieira via Development wrote: >>> On Tuesday 27 October 2015 09:05:34 kl222 via Development wrote: >>>> Thiago Macieira: >>>> >>>> 1. I think this is a bug. When using cmake project file, it has the >>>> responsibility to deal with it automatic dependency, rather than by the >>>> user >>>> to deal with. >>> >>> That might be. So please report it so this isn't forgotten. >> >> Please compare https://bugreports.qt.io/browse/QTBUG-38913 before >> reporting a bug. >> >>>> 2. No bug for qt. How to use .prl and .pc in cmake or pro file? >>> >>> In the .pro file, the .prl file is used automatically. You don't have to do >>> anything. You won't see this problem with qmake. >>> >>> Your problem is exclusive to cmake because the information is missing from >>> our >>> generated files. Matthew says there's a place to save them, but he doesn't >>> know how Qt's buildsystem generates such files. >>> >>> That's done in mkspecs/features/create_cmake.prf in qtbase using >>> mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in as a template. If anyone >>> can figure out how to save LIBS and LIBS_PRIVATE in the cmake file, that >>> should fix the problem. >> >> https://codereview.qt-project.org/#/c/33193/4 ? >> >> Looking a bit more closely, it looks like that may be stale beyond being >> able to apply. >> >> Looking at create_cmake.prf, I still don't understand what's going on >> :-). It looks like what needs to happen, though, is somewhere about >> where CMAKE_QT5_MODULE_DEPS is filled, another variable needs to be >> filled with the private dependencies. Then in Qt5BasicConfig.cmake.in >> where this is used, there needs to be an additional PP conditional to >> choose between just the public deps or both the public and private deps, >> depending if Qt is static. (There is already such PP conditionals for >> using the correct add_library(), so there is no issue with such an >> addition.) >> >> Very rough patch for the CMake side attached. (This won't fix the >> problem, it's just to demonstrate what I'm trying to say above.) If >> someone knows how to modify create_cmake.prf to stuff the appropriate >> private dependencies into CMAKE_QT5_MODULE_STATIC_DEPS, I think this >> should work. > > The MSYS2 project carries multiple patches to fix / implement Qt5 > static CMake support, at least one of them based on previous (since > reverted) work by Stephen Kelly. I've not got enough time to deal with > upstreaming them unfortunately. You can find them here: > > https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-static > (most of the patches from 0033- onwards). > > .. or you could use our qt5-static packages if you wish. I forgot to mention, we also have a patch for CMake to add an 'AUTOSTATICPLUGINS' feature so that the needed plugins get statically linked too: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-cmake/qt5-static-plugin-support.patch > > -- > Best regards, > > Ray. > >> >> -- >> Matthew >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 答复: Qt static compiler error
On Tue, Oct 27, 2015 at 2:48 PM, Matthew Woehlke via Development wrote: > (Apologies for reposting information, but my other message is stuck > somewhere in the moderation queue...) > > On 2015-10-26 22:58, Thiago Macieira via Development wrote: >> On Tuesday 27 October 2015 09:05:34 kl222 via Development wrote: >>> Thiago Macieira: >>> >>> 1. I think this is a bug. When using cmake project file, it has the >>> responsibility to deal with it automatic dependency, rather than by the user >>> to deal with. >> >> That might be. So please report it so this isn't forgotten. > > Please compare https://bugreports.qt.io/browse/QTBUG-38913 before > reporting a bug. > >>> 2. No bug for qt. How to use .prl and .pc in cmake or pro file? >> >> In the .pro file, the .prl file is used automatically. You don't have to do >> anything. You won't see this problem with qmake. >> >> Your problem is exclusive to cmake because the information is missing from >> our >> generated files. Matthew says there's a place to save them, but he doesn't >> know how Qt's buildsystem generates such files. >> >> That's done in mkspecs/features/create_cmake.prf in qtbase using >> mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in as a template. If anyone >> can figure out how to save LIBS and LIBS_PRIVATE in the cmake file, that >> should fix the problem. > > https://codereview.qt-project.org/#/c/33193/4 ? > > Looking a bit more closely, it looks like that may be stale beyond being > able to apply. > > Looking at create_cmake.prf, I still don't understand what's going on > :-). It looks like what needs to happen, though, is somewhere about > where CMAKE_QT5_MODULE_DEPS is filled, another variable needs to be > filled with the private dependencies. Then in Qt5BasicConfig.cmake.in > where this is used, there needs to be an additional PP conditional to > choose between just the public deps or both the public and private deps, > depending if Qt is static. (There is already such PP conditionals for > using the correct add_library(), so there is no issue with such an > addition.) > > Very rough patch for the CMake side attached. (This won't fix the > problem, it's just to demonstrate what I'm trying to say above.) If > someone knows how to modify create_cmake.prf to stuff the appropriate > private dependencies into CMAKE_QT5_MODULE_STATIC_DEPS, I think this > should work. The MSYS2 project carries multiple patches to fix / implement Qt5 static CMake support, at least one of them based on previous (since reverted) work by Stephen Kelly. I've not got enough time to deal with upstreaming them unfortunately. You can find them here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-static (most of the patches from 0033- onwards). .. or you could use our qt5-static packages if you wish. -- Best regards, Ray. > > -- > Matthew > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build qt fail
On Thu, Apr 9, 2015 at 7:47 AM, kl222 wrote: > Environment: > > Operation System: windows7 Ultimate > > Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys > > Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys) > > Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2 > > Perl: This is perl 5, version 20, subversion 2 (v5.20.2) built for > i686-msys-thread-multi-64int > > Python: Python 3.3.3 > > > > > > Error message: > > > > g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport > -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads > -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV > -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB > -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES > -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER > -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 > -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. -I../../include > -I../../include/QtCore -I../../include/QtCore/5.5.0 > -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre > -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 > -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o > .obj/release/qsimd.o tools/qsimd.cpp > > tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory > > #include > > ^ > > compilation terminated. > > Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' failed > > make[4]: *** [.obj/release/qsimd.o] Error 1 > > make[4]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:34: recipe for target 'release' failed > > make[3]: *** [release] Error 2 > > make[3]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:165: recipe for target 'sub-corelib-make_first' failed > > make[2]: *** [sub-corelib-make_first] Error 2 > > make[2]: Leaving directory '/d/source/qt5/qtbase/src' > > Makefile:41: recipe for target 'sub-src-make_first' failed > > make[1]: *** [sub-src-make_first] Error 2 > > make[1]: Leaving directory '/d/source/qt5/qtbase' > > Makefile:69: recipe for target 'module-qtbase-make_first' failed > > make: *** [module-qtbase-make_first] Error 2 > Hi, You need to post full reproduction instructions or a link to them to help us to diagnose this. > > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ARM GDB with Python support for Windows host
On Wed, Dec 10, 2014 at 9:31 AM, Denis Shienkov wrote: > Hi all. > > I trying to build a GDB (with python suport) for the ARM target on Windows > host (with MinGW/MSYS), > but without of result. It is failed on libiconv v1.14 building (a wrong > -DINSTALLDIR escaping without quotes in libcharset sub-dir). > > I use this WIKI: http://qt-project.org/wiki/QtCreatorBuildGdb > > Has anyone a URL to download a latest ready GDB binaries (at least v 7.8.x) > ? GDB 7.8.x doesn't demangle some C++ symbols (specifically one from Qt Creator) properly (it causes gdb to recurse until stack runs out). On MSYS2 I've pinned GDB to 7.6.2 because of that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 > > Because I see only a latest 7.4.x version from here: > > http://download.qt-project.org/development_releases/prebuilt/gdb/windows-7/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz > > Best regards, > Denis > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D Examples
On Tue, Oct 14, 2014 at 9:34 AM, Sean Harmer wrote: > On 14/10/2014 08:01, Koehne Kai wrote: >> >>> -Original Message- >>> From: development-bounces+kai.koehne=theqtcompany.com@qt- >>> [...] >>> I don't have an "authoritative" answer, but one possible option would be an >>> sub-module that contains the assets for examples or (easier?) separate the >>> Qt 3d examples and their assets into a standalone git repository. >> Keep in mind though that this will only help users that clone & build from >> git. People using the tar balls, prebuilt binaries , will still suffer, >> because (at least so far) we split up only the toplevel repositories . >> >> I'm not sure how 'big' big is in your case, but if it's an issue I'd rather >> go for another toplevel module . IMO there's a much better chance also e.g. >> Linux distributions will package this separately. > > Good point. This would then be analogous to the webkit-examples repo > too. It also means we can keep some simple light-weight examples in the > main Qt3D repo. > > Could I kindly propose, and if approved, request the creation of a > qt3d-examples module please? Is it sufficient to do that here or do I > also need to file a sysadmin JIRA task? What about using procedural generation for these assets, some plasma textures and geospheres? It'd look quite retro though I suppse. > > Many thanks in advance, > > Sean > > -- > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D on windows
On Sun, Oct 12, 2014 at 8:56 PM, Sean Harmer wrote: > Hi, > > just a quick heads up that Qt3D's wip/newapi branch now displays content > usign threaded rendering on windows. I've tested with MSVC 2012 OpenGL > x86_64 build with nVidia driver. Your mileage may vary with other > drivers, compilers and OpenGL configurations. I wouldn't be surprised to > find a few places need tweaks with a dynamic OpenGL build. Angle doesn't do multithreaded rendering, will it be possible to use Qt3D on Angle? > > There's still a crash on exit bug which I'm working on but if people > wish to contribute, using windows should now also be an option. > > We will also test some OpenGL ES 2/3 platforms soon and try to extend > our CI coverage to these platforms. > > Cheers, > > Sean > > -- > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt.io download-open-source page updated
I don't see any "Help us improve" button, so I'm emailing instead. On Tue, Oct 7, 2014 at 8:13 AM, Anttila Janne wrote: > Hi, > > Thanks for your feedback related to qt.io opensource downloads page: > http://www.qt.io/download-open-source/ > > The page is now updated based on your comments - the major changes are: > 1. Automatic download is now completely removed > * Recommended download is still highlighted and you can start download with > button click > 2. All downloads from http://qt-project.org/downloads page have been added > to new page > * No need to jump between sites anymore > > In addition some other smaller changes were implemented. We have some visual > Improvements in backlog, but those want change functionality or content of > the page. > > Does the page fulfil purpose & your needs now? If you have any comments, > please use "Help is improve" button on right hand side of the page. Why is "Mobile application distribution through public application stores" unticked for the community edition? You can make a LGPL Android application and distribute it on the Play Store. Perhaps a ? with clarification would be better? > > Br, > -- > Janne Anttila > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] `/opt/qt5/bin/qdoc: not found` with `-prefix /opt/qt5` config
You're repeating yourself without adding any explanatory information.
When releasing software for other people to use, normally you'd
package it elsewhere to -prefix, otherwise how do you untangle the Qt
files from the rest of your files?
As an example of this, from Arch Linux's Qt5 packaging function in the PKGBUILD:
package_qt5-base() {
..
cd ${_pkgfqn}/qtbase
make INSTALL_ROOT="${pkgdir}" install
On Fri, May 9, 2014 at 2:21 PM, Giuseppe D'Angelo wrote:
> On 9 May 2014 15:16, Ray Donnelly wrote:
>> On Fri, May 9, 2014 at 10:05 AM, Giuseppe D'Angelo
>> wrote:
>>> On 9 May 2014 10:53, Yuchen Deng wrote:
>>>> If I have to do `make install` first, then I can't use `make install
>>>> INSTALL_ROOT=$PWD/qt` anymore.
>>>> It's means INSTALL_ROOT does not support for this case?
>>>
>>> What do you mean? "make install" will install in the directory you
>>> chose with the -prefix option. Why do you want to override that now?
>>>
>>
>> -prefix is where you want it to finally end up on the users' computer,
>> but INSTALL_ROOT is where you want it to get installed to so you can
>> package it cleanly.. usually.
>
> You can't package it in any other place rather than -prefix. Just use
> "make install" before "make docs".
>
> --
> Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] `/opt/qt5/bin/qdoc: not found` with `-prefix /opt/qt5` config
On Fri, May 9, 2014 at 10:05 AM, Giuseppe D'Angelo wrote: > On 9 May 2014 10:53, Yuchen Deng wrote: >> If I have to do `make install` first, then I can't use `make install >> INSTALL_ROOT=$PWD/qt` anymore. >> It's means INSTALL_ROOT does not support for this case? > > What do you mean? "make install" will install in the directory you > chose with the -prefix option. Why do you want to override that now? > -prefix is where you want it to finally end up on the users' computer, but INSTALL_ROOT is where you want it to get installed to so you can package it cleanly.. usually. > -- > Giuseppe D'Angelo > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.3 RC snapshot available
Same here. Seems eminently sensible to allow easy testing of these candidates from source. On Apr 23, 2014 8:09 AM, "Peter Kümmel" wrote: > On 22.04.2014 07:17, Heikkinen Jani wrote: > > Hi all, > > > > We have new RC snapshot available in > http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-21_65/ > > I tried to update my build scripts, but there are no source packages > available. > Isn't a RC a simulation of the release? > > Thanks, > Peter > > > > > > Mirroring is ongoing but all installers should be available later today. > Please test these & verify your fixes! > > > > Qt5 changes in these packages: > > > > https://codereview.qt-project.org/#change,83700 : > > > > Patch Set 4: > > > > * qtbase 8b0fd78...13e3f26 (7): > > > > > QPrintDialog - Fix Mac reference counting error. > > > > > QPrintDialog - Fix mac change of printer name > > > > > Android input method fix > > > > > Revert "Automatically link printsupport plugins to static > applications." > > > > > When a window loses focus to a popup, event has PopupFocusReason > > > > > Restore Qt 4 behavior in default double click handler > > > > > Remove internal public function from QOpenGLFunctions > > > > * qtdeclarative fc634cb...0076835 (6): > > > > > qmlplugindump: correctly merge composite types > > > > > QQuickItemView/QQuickPathView: Fix creation of delegates > > > > > Make sure the clipPath is retained as state of Context2D > > > > > Prevent a crash when the item is deleted but not removed from cache > > > > > Refine fix for dynamic properties on QObjects wrapped in JavaScript > > > > > V4: fix register usage on ARM. > > > > * qtdoc e006b84...66ade86 (2): > > > > > Doc: Various fixes to Enginio related links. > > > > > Doc: command line tools need not be installed separately > > > > * qtlocation 8ff60b5...4f2990d (1): > > > > > Add Qt 5.3.0 change log for QtPositioning. > > > > * qtmultimedia af73d55...4c8284d (1): > > > > > Rework qmlvideofx example > > > > * qtquickcontrols f067a73...786164e (2): > > > > > Update plugins.qmltypes for QtQuick.PrivateWidgets > > > > > Update plugins.qmltypes for QtQuick.Dialogs > > > > * qtrepotools ee57020...04c900d (1): > > > > > ignore symlinks > > > > * qtsensors e60743e...8a0da79 (3): > > > > > ios: skip accelerometer, gyroscope and magnetomenter updates if NaN > > > > > accelbubble: disable rotation on iOS > > > > > accelbubble: avoid updating position if NaN. > > > > * qttranslations 6e972b4...d56737b (3): > > > > > Update Japanese translations. > > > > > Russian translation update > > > > > Ukrainian translation update > > > > https://codereview.qt-project.org/#change,83673 : > > > > Patch Set 2: > > > > * qtbase 3f9ad1e...8b0fd78 (2): > > > > > WinRT: Dont use the native thread handle for waiting > > > > > iOS: fix crash in auto correction when using unknown font family > > > > * qtconnectivity d755d1e...9b11226 (1): > > > > > Fix discovery hanging in unrecoverable state due to incorrect error > handling > > > > * qtdeclarative 1b3a930...fc634cb (1): > > > > > Doc: Improved Qt Quick Demos documentation > > > > * qtmacextras abbb6d3...ddbbc1f (1): > > > > > Doc: Improved example documentation. > > > > * qtquickcontrols 6d438f3...f067a73 (1): > > > > > Docs: fix QtQuick.Controls.Styles import version > > > > Br, > > > > Jani > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing)
On Wed, Feb 12, 2014 at 12:03 PM, Koehne Kai wrote: > > >> -Original Message- >> From: development-bounces+kai.koehne=digia@qt-project.org >> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On >> Behalf Of Markus Goetz >> Sent: Wednesday, February 12, 2014 11:45 AM >> To: development@qt-project.org >> Subject: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release >> Testing) >> >> Hi Kai, >> >> On 25.10.13 10:05, Koehne Kai wrote: >> > I think the link is outdated. MinGW-builds nowadays supported both dw2 >> and sjlj exception handling for 32 bit since ages, see e.g. >> > >> > http://mingw-w64.sourceforge.net/download.php#mingw-builds >> > >> > (Note that the Mingw-w64 and MinGW-builds projects joined forces just >> recently, so the mingw-builds binaries are the 'officially endorsed' ones). >> > >> > Anyhow, Qt itself doesn't really care about SJLJ vs dw2: It compiles just >> > fine >> with both versions. It's just that, since 5.1, we're building the 'official' >> packages with a dw2 toolchain. >> > >> Are there any plans to also provide official SJLJ packages for mingw-w64 ? > > No, there aren't any plans AFAIK. If we'll add a new configuration it'll most > likely be a 64 bit one, and we really can't stretch the number of Windows > binary packages much further. > >> Right now people that don't want to build themselves have to go 3rd >> party sites like >> http://sourceforge.net/projects/qtx64/files/qt-x64/5.2.1/mingw-4.8/ > > I don't know about this project. However, the mingw-builds folks are also > providing Qt packages, which I can only recommend: > > http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages > > I'm all for featuring these a bit more prominently within Qt ... That would be great. The Qt-builds project has morphed a bit (it's now built via the MSYS2 project). While Qt-builds is fantastic, MSYS2 is IMHO the best thing to happen to Open Source on Windows since MinGW-w64. Alexey ported Arch Linux's pacman package manager and a large set of MSYS2 packages as well as ones for Windows 32bit and Windows 64bit, including of course Qt5, QtCreator and Qbs (and hundreds more packages). You can see the PKGBUILD and patch files here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qtcreator https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 Installing Qt5 and all its dependencies is as easy as: pacman -S mingw-w64-i686-qt pacman -S mingw-w64-x86_64-qt building if from source isn't *much* more complicated than: cd /c/repo/mingw-w64-qt5 makepkg-mingw The only real documentation we've got is: http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ Arch Linux users/developers should be quite at home in this environment. > >> (Yes, SJLJ is inferior to SEH, but sometimes you don't control the whole >> stack/hell of DLLs and just need to use SJLJ) MSYS2's Win64 GCC is SEH (and hence so are all the Win64 packages). > > Understood. We just made the choice for DW2 because SJLJ was a lot slower, > even for people who don't use exceptions. > > Regards > > Kai > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tips needed on doing cross-platform building/testing
My usual approach for testing before exposing to the world is to use git format-patch -1 Then patch -p1 < 0001-Some-commit-message.patch I use Dropbox to share patch files. On Sep 28, 2013 12:14 AM, "Koehne Kai" wrote: > > -Original Message- > > [...] > > If by share with the VM you mean via a shared folder, I wouldn't > recommend > > it, Qt uses in-tree builds so you'd be forever having to "git clean > -dfx" and > > rebuild from scratch every time you switched OS's, and believe me given > > how slow Git and Qt is building in a Window's VM then you don't want to > do > > that often. > > Qt builds just fine in a shadow build setup. The only caveats are that it > should be on the same file system level than the source directory, and that > your source directory should be really clean (e.g. not containing any build > artifacts). I'm using this setup since forever ... > > Just saying, > > Kai > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moc with clang.
Someone should tell Google who have recently ported it to Android. On Wed, Jul 3, 2013 at 4:46 PM, Thiago Macieira wrote: > On quarta-feira, 3 de julho de 2013 13.12.02, Tr3wory wrote: > > Also the libc++ std library implementation has issues on windows, > > libc++ isn't meant to work outside of OS X. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moc with clang.
If a project releases binary packages for a given OS, but they aren't able to make binaries for the latest version and if the latest release for that OS is marked experimental, then that fits my definition of "not mature". Also, not having 64bit doesn't point to much maturity (nor does forcing fixed installation paths on any system - last time I checked clang was like this). On Wed, Jul 3, 2013 at 12:31 PM, Laszlo Papp wrote: > It is really strange then they do not provide "mature" installers for the > mature parts. > > > On Wed, Jul 3, 2013 at 11:12 AM, Tr3wory wrote: > >> Maturity of clang on windows is a little complicated: >> First you can use 2 ABI: gcc/mingw or msvc. >> As far as I know the first is kind of working while the second has >> serious issues. >> >> Also the libc++ std library implementation has issues on windows, >> while the libstdc++ (from mingw 4.8) works. >> >> But this is about the clang used as a full compiler. >> >> If you use only the libclang as a c++ parser, then it's as good as >> everywhere else. And the moc-ng used as a drop in replacement of moc >> use only this. (Using as a clang plugin is a different story.) >> >> tr3w >> >> On Tue, Jul 2, 2013 at 6:05 PM, Laszlo Papp wrote: >> > On Tue, Jul 2, 2013 at 3:24 PM, Konstantin Tokarev >> > wrote: >> >> >> >> > So, it could not be even optional because clang is not mature enough >> on >> >> > Windows, and in other scenarios or there is any other reason? >> >> >> >> Clang is quite mature on Windows, at least when used as C++ parser. >> > >> > >> > Why I thought that was because I do not see pre-built Windows clang >> binaries >> > for the latest version, and even before that, it had been marked as >> > "Experimental". Not sure about 64 bit, debug, openmp (few projects >> still use >> > that, yeah), other scenarios, et cetera. >> > >> > Perhaps, if you build it yourself, it might work, but still. :-) >> > >> > Cheers, >> > Laszlo >> > >> > ___ >> > Development mailing list >> > Development@qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> > >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out)
> Relevant for Qt Since Qt is an application framework, I think relevant for Qt implies "relevant for Qt and any project that uses it". IMHO the goal should be to fully support build systems to the extent they work on each platform or dropping that build system. CI'ing weird corner-case builds is important as they tend to catch more issues than vanilla builds do (and that most developers also likely run); ideally you'd have full coverage. On Wed, Jul 3, 2013 at 11:28 AM, Tor Arne Vestbø wrote: > On 7/3/13 12:12 , Laszlo Papp wrote: > > On Mon, Jul 1, 2013 at 2:10 PM, Tor Arne Vestbø > > mailto:tor.arne.ves...@digia.com>> wrote: > > > > There is also the question of platform support. Is cmake as relevant > on > > Windows or OSX as it is on Linux? More so? > > > > > > Not sure what exactly you mean by relevant, but cmake is a > > /cross/-/platform/, open-source build system. It has been used on > > Windows and OS X extensively out there for a while. > > Relevant for Qt. > > What percentage of Qt developers develop on Windows? > Out of those, what percentage use cmake over qmake? > > At some point the cost of maintaining (blocking CI integration e.g.) a > build system (or any feature) that has a low relevance on a given > platform becomes higher than the benefit. > > tor arne > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 installers ready for testing
In that case, good luck dealing with all those bug reports due to vendors not caring about OpenGL on random bits of hardware. I'd assume people shipping software would prefer less headaches. I've never tried to use multisampling but have found: http://www.khronos.org/registry/gles/extensions/ANGLE/ANGLE_framebuffer_multisample.txt Have you got any references to the multisampling bug? I've not found any so far and I'm sure it can't be hard to fix. The rate of changes to angleproject is fairly amazing, I wouldn't bet against it (both Chromium and Firefox use it for WebGL of course) https://code.google.com/p/angleproject/source/list I disagree strongly about not providing ANGLE builds by default, and would go the other way to spare developers' sanity. Hoping that vendors will fix their OpenGL drivers is IMHO tilting at windmills. On Wed, Jun 12, 2013 at 10:55 AM, Mark wrote: > I much prefer OpenGL. I've seen plenty of bugs caused by angle (like > no multisampling which is still an open issue and reported) that made > me switch to Qt 5.1 builds with OpenGL native. Also imho ANGLE is just > a lame excuse to be able to use OpenGL "properly" because the native > OpenGL is poorly supported by the driver vendors. > > The problem is them, the driver vendors, aka AMD, Nvidia en Intel with > heavy emphasis on AMD. They (especially AMD) neglect to make decently > working OpenGL drivers and they should be heavily pushed to fix their > crap. ANGLE should not need to exist. > > I think Qt shouldn't provide an ANGLE build by default but have a > runtime option to use it. Optional and not enabled by default. > > On Wed, Jun 12, 2013 at 11:23 AM, Ray Donnelly > wrote: > > I much prefer angleproject to 'native' OpenGL on Windows. > > > > Mainly because you can compile and then debug into the 'driver' should > you > > need to. > > > > > > On Wed, Jun 12, 2013 at 10:18 AM, Axel Waggershauser > > wrote: > >> > >> On Wed, Jun 12, 2013 at 9:34 AM, Koehne Kai > wrote: > >> >> Subject: Re: [Development] Qt 5.1 installers ready for testing > >> >> > >> >> What about a windows mingw "non-opengl" (a.k.a. ANGLE) package? Any > >> >> plans > >> >> regarding that? If there should be a perceived lack of interest: > >> >> I am interested :). > >> > > >> > Just out of interest, why would you prefer ANGLE packages over OpenGL? > >> > >> To benefit from the advantages that ANGLE was introduced for in the > >> first place: getting better overall stability/usability due to > >> avoiding the myriad of buggy/outdated OpenGL drivers out there. Also, > >> I started a recent project with the mingw ANGLE installer for 5.0.1 > >> (the only mingw installer provided up until now) and although I am > >> really happy to be able to play around with proper OpenGL now, I'd > >> still very much welcome (rely on, actually) being able to ship this > >> one project linked against ANGLE. > >> > >> Ideal of course, would be, if this would eventually be merged down to > >> one package with a link-time switch, maybe even a runtime switch. > >> > >> - Axel > >> ___ > >> Development mailing list > >> Development@qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 installers ready for testing
I much prefer angleproject to 'native' OpenGL on Windows. Mainly because you can compile and then debug into the 'driver' should you need to. On Wed, Jun 12, 2013 at 10:18 AM, Axel Waggershauser wrote: > On Wed, Jun 12, 2013 at 9:34 AM, Koehne Kai wrote: > >> Subject: Re: [Development] Qt 5.1 installers ready for testing > >> > >> What about a windows mingw "non-opengl" (a.k.a. ANGLE) package? Any > plans > >> regarding that? If there should be a perceived lack of interest: > >> I am interested :). > > > > Just out of interest, why would you prefer ANGLE packages over OpenGL? > > To benefit from the advantages that ANGLE was introduced for in the > first place: getting better overall stability/usability due to > avoiding the myriad of buggy/outdated OpenGL drivers out there. Also, > I started a recent project with the mingw ANGLE installer for 5.0.1 > (the only mingw installer provided up until now) and although I am > really happy to be able to play around with proper OpenGL now, I'd > still very much welcome (rely on, actually) being able to ship this > one project linked against ANGLE. > > Ideal of course, would be, if this would eventually be merged down to > one package with a link-time switch, maybe even a runtime switch. > > - Axel > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Webkit build failing because W32 command-line length limit
The patches for msys are minor (and being merged). Check Qt-builds project on sourceforge. On 16 May 2013 22:49, "Bruno Souza Cabrral" wrote: > @andy, > I'm building from "c:/q" and it far exceed the limit to be related to the > folder path alone. > > > @Ray , > I think that build from cmd is the recommended scenario for W32. > MSYS is the other option, but it do not work without patches. > > On Thu, May 16, 2013 at 6:31 PM, andy fillebrown < > andy.fillebr...@gmail.com> wrote: > >> I don't build the WebKit module anymore, but when I did I made sure the >> Qt source tree was in a directory with a very short name, like D:\Qt-5.1.0. >> That way the command line stays small enough to make it through the build. >> >> Cheers, >> ~ andy.f >> >> >> >> >> >> On Thu, May 16, 2013 at 4:05 PM, Bruno Souza Cabrral wrote: >> >>> Hello, >>> >>> For a while, I can't do any W32 builds with Webkit installed, because it >>> hit a command-line limit and fails. >>> >>> The cmd in Windows have an 8191 characters limit where during the webkit >>> build it far extrapolate this. >>> >>> Attached there is a example, where the gcc invocation contains 9890 >>> characters ! >>> >>> This can be extremely frustrating because a build will randomly fail >>> with a random cryptically message depending on the build env and the folder >>> name. >>> >>> One solution I can see is moving the defines bundled in the gcc >>> invocation to a header. But I can't see a easy way of doing this. >>> >>> Suggestions ? >>> >>> []'s >>> Bruno >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Darwin (OSX and iOS) cross compilers for Linux and Windows (and Darwin).
Hi,
First of all, I hope this isn't too off topic for this list; I'll be
looking to use qbs with these compilers to build Necessitas Qt Creator
fwiw. If cross posting to both the qbs and qt developers mailing lists
is frowned upon then accept my apologies.. Having said that, I
would've posted this to the qt-interest list too if I'd proved that I
can build qt apps on Linux targeting OS X, but I won't get round to
that until I've finished some Android NDK work using these
toolchains...
I've been busying myself lately with some cross compilers targeting
Darwin. I've compiled both gcc and llvmgcc and am fairly up to date
with Apple's releases. Here are the links:
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120501.7z
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120501.7z
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Darwin-120501.7z
..release notes with changelog can be found at:
http://code.google.com/p/mingw-and-ndk/downloads/detail?name=multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120501.7z
Both i686 and x86_64 (+multiarch) works for OS X, and both armv6 and
armv7 (+multiarch) works for iOS. I've expended a reasonable amount of
effort to make sure that the toolchains are relocatable, so you should
be able to put them where you want (provided you maintain the relative
layout of course)
You also need to provide your own MacOSX10.7.sdk or iPhone4.3.sdk as I
can't legally distribute these. I haven't tested with any other
versions but most like they'll work fine.
The compiler driver programs (which enable multiple -arch flags) are
in the apple-osx/bin and apple-ios/bin folders and their names follow
the pattern:
apple-(osx|ios){-llvm}-(g++|gcc)
..where {-llvm} is optional.
It's not necessary to add apple-osx/bin or apple-ios/bin to your PATH,
though for some configury scripts this will be required.
To pass the SDK location, use --sysroot $somewhere/MacOSX10.7.sdk or
$somewhere/iPhone4.3.sdk
..for OS X, you should add (something like) -mmacosx-version-min=10.5
-DMAXOSX_DEPLOYEMENT_TARGET=10.5
..and for iOS you should add (something like) -miphoneos-version-min=2.0
I've tested these far as as compiling and executing the entire Google
Android NDK (build machine was GNU/Linux x86) and as far as compiling
and executing "Hello World", both C and C++ on iPhone (build machine
was Win32).
The executables are 32bit for all 3 hosts.
Bug reports to mingw.android at gmail dot com would be very welcome.
Best regards,
Ray Donnelly.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
