summaryrefslogtreecommitdiffstats
path: root/mkspecs/features
Commit message (Collapse)AuthorAgeFilesLines
* Place classes from private headers in the Qt_5_PRIVATE_API ELF versionThiago Macieira2015-10-202-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | This way, it's possible to tell which applications and libraries depend on the Qt private API and of which Qt library. Linux distributions can use this information to decide which applications need to be recompiled every time Qt itself is rebuilt. This is done by scanning all class and struct definitions in the private headers (we've already got the list from syncqt). I opted to add a new script instead of modifying syncqt because then this can run in parallel with the rest of the compilation, as opposed to during qmake time. Another advantage is that it catches modifications to the headers in between qmake executions. Since this is already Unix specific, it should be no problem to use Perl. This solution is limited to use of non-inline symbols of classes declared in private headers. It will not catch free variables (such as qsimd_p.h's qt_cpu_features), use of inlined functions or just plain use of a class/struct for accessing its data members. However, this is already better than nothing and should help Linux distributions quite a lot. And there's no way to catch the latter issue anyway. Change-Id: I049a653beeb5454c9539ffff13e3fff36400ebbd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* don't try to use relative rpaths on platforms that don't support itOswald Buddenhagen2015-10-201-1/+1
| | | | | Change-Id: I8224d429d71ccc829beb1addf592806d2edaa87b Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* support relative paths in QMAKE_RPATHDIROswald Buddenhagen2015-10-201-7/+1
| | | | | | | | | | | | | | | | ... and make use of it in qt.prf. [ChangeLog][qmake][Unix] Added support for relative paths in QMAKE_RPATHDIR. Note that this technically breaks backwards compatibility, as relative paths were previously silently resolved against $$_PRO_FILE_PWD_. This was not documented and seems rather useless, so i'm not worried. Change-Id: I855042a8962ab34ad4617899a5b9825af0087f8a Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Update qversiontagging.cpp not to use too much assembler magicThiago Macieira2015-10-201-2/+6
| | | | | | | | | | | | | | | The only reason I had used them in the first place was because C preprocessor macros cannot call themselves recursively. But the magic was too magic and caused issues with some builds, so let's choose the safer option. Anyway, this solution now works for all ELF architectures, independent of the processor, whereas previously it was restricted to x86 and Linux/ FreeBSD. However, this does not apply to the assembly in qversiontagging.h. Change-Id: I42e7ef1a481840699a8dffff1404f032fc5cacb8 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* winrt: Avoid empty <Dependencies> section in manifest filesOliver Wolff2015-10-201-0/+4
| | | | | | | | | | If that section is there but empty, the manifest cannot be loaded using the App Manifest Designer in Visual Studio. Task-number: QTBUG-48648 Change-Id: I529eb2f2a690bececcf5c385b8f96e84ece363d6 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
* Turn C++11 on by default if the compiler supports C++11Thiago Macieira2015-10-161-0/+2
| | | | | | | | | | | | | | [ChangeLog][Important Behavior Changes] qmake now enables C++11 support by default if the compiler is known to support it (unless the compiler defaults to C++14 or a later edition). To disable this, add to your .pro file: CONFIG -= c++11. Note that Qt 5.7 will require C++11 support, so it is a good idea to ensure your code works with that compiler setting. (Note: it is not possible to disable C++11 support with Microsoft Visual Studio) Change-Id: Ib056b47dde3341ef9a52ffff13ef13ee2cf888eb Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com> Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* tools: use QStringBuilderMarc Mutz2015-10-151-0/+1
| | | | | | | | | | src/tools/bootstrap was already compiled with QT_USE_STRINGBUILDER, by way of load(qt_module), but the actual apps weren't. Some apps become smaller, some larger; all (presumably) faster. Change-Id: Idc8662e62ec14b27e730de9842bec295a1b5566e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Distinguish between Objective-C and Objective-C++ sourcesTor Arne Vestbø2015-10-098-30/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources into the same pile, passing them on to the same compiler as for C++ (CXX), with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as variants of the C and C++ languages separately, so that Objective-C sources are built with CC and with CFLAGS, and Objective-C++ sources with CXX, and CXXFLAGS. This lets us remove a lot of duplicated flags and definitions from the QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched the C++ equivalent. The remaining Objective-C/C++ flags are added to CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in C/C++ mode. This matches Xcode, which also doesn't have a separate build setting for Objective-C/C++ flags. The Makefile qmake generator has been rewritten to support Objective-C/C++ fully, by not assuming that we're just iterating over the C and C++ extensions when dealing with compilation rules, precompiled headers, etc. There's some duplicated logic in this code, as inherent by qmake's already duplicated code paths, but this can be cleaned up when C++11 support is mandatory and we can use lambda functions. Task-number: QTBUG-36575 Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Merge "Merge remote-tracking branch 'origin/5.5' into 5.6" into refs/staging/5.6Liang Qi2015-10-021-1/+1
|\
| * Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-021-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: qmake/doc/src/qmake-manual.qdoc src/corelib/tools/qstring.h src/gui/image/qimagereader.cpp src/network/access/qnetworkaccessmanager.cpp src/tools/qdoc/doc/examples/examples.qdoc src/widgets/accessible/qaccessiblewidgetfactory_p.h src/widgets/doc/qtwidgets.qdocconf Change-Id: I8fae62283aebefe24e5ca4b4abd97386560c0fcb
| | * Windows: Change the mocinclude extension to .optAndy Shaw2015-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cleaning in Visual Studio then it will remove all instances of tmp files which meant it would remove the mocinclude.tmp as well incorrectly. Therefore the extension of the mocinclude file needs to be changed to .opt so that it is left untouched by Visual Studio. Change-Id: Iebc055f33f9dc87a4fa42ae87b253f6739903e8f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | | remove now superfluous QMAKE_*_VERSION_OVERRIDEsOswald Buddenhagen2015-10-021-6/+0
|/ / | | | | | | | | | | | | | | | | | | | | these were necessary to suppress the appending of the qt major version to the library name when reading .prl files. this has outlived its usefulness, as the .prl files now contain the full library name. additionally, the overrides would break the use of qt if the .prl files were not shipped, as zero lost its special meaning as "none". Change-Id: I9f028c17fc0428cb546a4a26ee209febff32da5e Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | unify handling of library prefixes and extensionsOswald Buddenhagen2015-10-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | make sure that all specs define QMAKE_{PREFIX,EXTENSION}_{SH,STATIC}LIB, and adjust the code to make halfways consistent use of these variables, in particular on windows; Win32MakefileGenerator::getLibTarget() is gone as a result, as is QMAKE_CYGWIN_SHLIB. still, tons of hardcoded "lib" references remain in the unix generator, because no-one cares. Change-Id: I6ccf37cc562f6584221c94fa27b2834412e4e4ca Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | omit trailing /. from relative RPATHs pointing to own directoryOswald Buddenhagen2015-10-011-2/+8
| | | | | | | | | | Change-Id: Ia4551f5b16f4e66c7ab7fdec82643d9cd8866ccd Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | more accurate check for presence of target INSTALLOswald Buddenhagen2015-10-011-1/+2
| | | | | | | | | | | | | | make it match qmake's own rules. Change-Id: Ia6b9ac12ac08932ac67f100f4638352a214553bd Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | Remove unused font deployment featureAndrew Knight2015-09-301-62/+0
| | | | | | | | | | | | | | | | This is a leftover from the unsupported Windows Phone 8.0 mkspec. Change-Id: Ibcf11e131a3cb098960410dbd683eb5950b0c5ad Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com> Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
* | Use QMAKE_MOD_LEX/QMAKE_MOD_YACC in lex/yacc featuresAndrew Knight2015-09-242-7/+7
| | | | | | | | | | | | | | | | These variables were defined but never used in the respective qmake features. Utilizing them allows more control over the output file name. Change-Id: I5ba96c5cd330b18dc060f563186992fe3bd27b49 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Update the list of compilers we are free of warnings withThiago Macieira2015-09-221-6/+6
| | | | | | | | | | | | | | | | | | I've tested with Clang 3.7 and ICC 16 on Linux, XCode 6.4 on OS X for OS X (not iOS). Change-Id: Ib306f8f647014b399b87ffff13f1f4291d801a20 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | inline qtAddModules() and dependenciesOswald Buddenhagen2015-09-172-124/+105
| | | | | | | | | | | | | | | | there is no particular reason to have them in qt_functions.prf any more, while the separation made the code harder to follow. Change-Id: Ie44c9784358f382f7bc863b421ff5b440211d66f Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | change implementation of deprecated qtAddLibrary() to modify QTOswald Buddenhagen2015-09-171-1/+2
| | | | | | | | | | | | | | | | | | ... instead of invoking qtAddModule() directly. gives better decoupling and unified code paths. Change-Id: I4a456ae3b8027aa65b8a4fba7ee5c171ae89be0c Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | inline qtAddRpathLink()Oswald Buddenhagen2015-09-172-18/+13
| | | | | | | | | | | | | | there is no particular reason to have it in qt_functions.prf. Change-Id: I88ed1ea937a9a88a4625a6de7bcd3a29957560da Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | sanitize qt rpath handling, in particular on macOswald Buddenhagen2015-09-176-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the addition of qt's rpath belongs into qt.prf - even on mac. so consolidate the two implementations. as a nice "side effect", we get relative rpaths also on linux. another "side effect" is that we don't unnecessarily add the qt rpath to qt modules also on linux. the qt rpath addition mechanism should not be responsible for setting the policy who gets a relative rpath, so move the logic to higher-level callers. Change-Id: I52e8fe2e8279e7b1ac25fae758867a5cb1cafcf8 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | simplify qt rpath codeOswald Buddenhagen2015-09-173-15/+5
| | | | | | | | | | | | | | | | | | the rpath applies only to the installed on-device location and is consequently always the same for all modules, so there is no point in indirections. Change-Id: Ia0590552aa317d799a2d3879fd0c0768344b9645 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove dead code re QTLIBOswald Buddenhagen2015-09-171-4/+0
| | | | | | | | | | | | | | this variable is not referenced anywhere else. Change-Id: Ib4d0a47a08d029f65542e752fa2a47c992e061fa Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove boundschecker exclusion hackOswald Buddenhagen2015-09-171-12/+0
| | | | | | | | | | | | | | | | the old plugin loader which test-loaded plugins (without their dependencies) is gone, so the hack is obsolete. Change-Id: I68077cb58174dfbcb0b5372e2574de41f48d35c9 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove some mac multiarch vestigesOswald Buddenhagen2015-09-171-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ppc/ppc64 and 32-bit x86 have been dead for a while. consequently, the legacy macx-g++-64 spec was most probably not used. which in turn meant that NATIVE_64_ARCH was never set (in particular on windows hosts ...), which means that the android ndk host auto-detection was effectively broken. the arch code in mac/default_post.prf was also never triggered, so nuke it as well. Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Fix QMAKE_CXX/CROSS_COMPILE verification with ccacheBenoît Thébaudeau2015-09-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of ccache leads to QMAKE_CXX definitions of the form: QMAKE_CXX = $${CCACHE} $${CROSS_COMPILE}g++ The previous test required QMAKE_CXX to be a single valid (absolute or QMAKE_PATH_ENV-relative) path to an existing file, which was not compatible with definitions of QMAKE_CXX like the one above. Fix this by using only the first value in QMAKE_CXX, which usually points to the compiler executable, or to the ccache executable in the above case. Task-number: QTBUG-47951 Change-Id: Iade3136f03493593b067fb7742fb997f92377425 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Do not install example sources when using vc(x)projOliver Wolff2015-09-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | Inside Visual Studio these files (INSTALLS) will end up in deployment. They do not make sense there and might even cause clashes, which prevent the project file from being loaded (for example when a qrc file is added to "Resource files" and "Deployment files") Change-Id: Ifa68c52a83b2bf3948738c7aa1cf9c56b331dc80 Reviewed-by: Andrew Knight <andrew.knight@intopalo.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | Add a linker version script to Qt librariesThiago Macieira2015-09-131-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This linker script is only enabled for systems with GCC or GCC-like compilers, though technically it should work on the BSDs too (will enable after testing). For regular modules, this declares one ELF version "Qt_5" and places all QtCore symbols inside, then it declares unused ELF versions "Qt_5.x" for each older minor release. For modules declared "internal_module", all symbols are placed in version Qt_5_PRIVATE_API. The big advantage of an ELF version is that, when we do Qt 6, both versions of QtCore could be loaded in memory without conflicts and all symbols would be resolved to the correct library. No module can talk to both at the same time, but this avoids mistakes of loading them indirectly by plugins. The extra Qt_5.x versions will be used in the next commit. Change-Id: I049a653beeb5454c9539ffff13e3fe6f050fdf31 Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Add detection of C++14 and C++1z compiler featuresThiago Macieira2015-09-055-35/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][General Improvements] Qt's buildsystem now detects whether the compiler supports C++14 and experimental support for C++1z. If the compiler supports it, then Qt is automatically compiled using that support. \ This does not apply to user applications built using qmake: those are still built with C++11 support only. To enable support for C++14 in your application, add to your .pro file: CONFIG += c++14 (similarly for C++1z). Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-08-262-4/+25
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: qmake/doc/snippets/code/doc_src_qmake-manual.pro qmake/doc/src/qmake-manual.qdoc src/corelib/io/qstorageinfo_unix.cpp src/corelib/tools/qbytearray.cpp src/widgets/kernel/qwidgetwindow.cpp tests/auto/corelib/io/qprocess/tst_qprocess.cpp tests/auto/corelib/mimetypes/qmimedatabase/tst_qmimedatabase.cpp tests/auto/network/access/qnetworkreply/BLACKLIST Change-Id: I9efcd7e1cce1c394eed425c43aa6fce7d2edf31c
| * WinRT: Link against correct c-runtimeMaurice Kalinowski2015-08-071-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to move adding ucrt(d).lib out of the various qmake.conf as qmake.conf is only parsed once by qmake and does not differentiate between debug and release. Hence use default_pre.prf which is the earliest prf to use. This one also is being parsed multiple times and does what it is supposed to do. This allows API certification tests for Win10 to suceed, another sideeffect is that it is much cleaner at a single location now. Change-Id: Id899f4bbd063a3191c8f139857abf90efa827ffc Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
| * WinRT: Add dependency support for Win10Maurice Kalinowski2015-08-061-4/+5
| | | | | | | | | | | | | | | | | | | | So far the dependency keyword has been ignored for the new Windows 10 mkspecs. The difference to older manifest files is that there is already a <Dependency> section and hence we embed dependencies inside this one, as the format standard does not allow to have multiple of those. Change-Id: I1bf25979cc28d5c153215de5bb9cd6f37e9c50aa Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
| * WinRT: Add manifest and assets to install rulesMaurice Kalinowski2015-08-061-0/+8
| | | | | | | | | | | | | | | | | | This enables to create fully functional packages from the output of 'nmake install'. Change-Id: Ief83532cdfc4575f7c42f5bb6a3cee4c9f0ecbd3 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
* | Require more of the C++11 Standard LibraryThiago Macieira2015-08-061-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since libstdc++ builds on OS X and QNX 6.5 are no longer supported, simply require <initializer_list> and std::move in order to claim C++11 support works. The minimum OS X versions need to be fixed elsewhere. Change-Id: Ib056b47dde3341ef9a52ffff13ef1d2ac3923f5c Reviewed-by: Marc Mutz <marc.mutz@kdab.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Jake Petroules <jake.petroules@petroules.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com> Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
* | Update/fix the qmake support for (f)lexThiago Macieira2015-07-311-6/+15
| | | | | | | | | | | | | | | | | | | | lex.prf was trying to be halfway between the standard POSIX lex requirements and those of GNU flex. So fix it to work with both, more or less, by noticing when lex is actually flex and using the extended GNU options. Note that POSIX lex is untested and may still not work. Change-Id: Ib306f8f647014b399b87ffff13f1e8e43fb68b3c Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | Update/fix the qmake support for yaccThiago Macieira2015-07-201-6/+6
| | | | | | | | | | | | | | | | | | yacc.prf was mostly working, so this commit simply makes it slightly better by using the -p and -b options that POSIX requires and avoid having a common intermediate file. Change-Id: Ib306f8f647014b399b87ffff13f1e8e74ad4db1d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Make CONFIG += c++11 by default not disable GNU extensionsThiago Macieira2015-07-173-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prefer -std=gnu++11 unless strict_c++11 is defined. You can enable strict C++11/C++14 mode by using CONFIG += strict_c++ That is enabled for Qt's own code, so we we don't accidentally use GNU extensions in portable code. There's no support for strict C++98 mode (that is, the -ansi option). [ChangeLog][qmake] By default, GNU extensions are now enabled with Clang, GCC and ICC even in C++11 and C++14 modes. To disable the GNU extensions, add to your .pro file: CONFIG += strict_c++. Change-Id: Ib056b47dde3341ef9a52ffff13ef14de2169bef5 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into HEADSimon Hausmann2015-07-172-5/+5
|\| | | | | | | | | | | | | Conflicts: src/plugins/platforms/windows/qwindowsopengltester.cpp Change-Id: Ia7abeba9395ccf84e2fa81b91a5725a86dedb9fe
| * Update the list of compilers we are free of warnings withThiago Macieira2015-07-171-4/+4
| | | | | | | | | | | | | | | | | | I've tested with GCC 5, Clang 3.5 and 3.6 on Linux. Change-Id: Ia0aac2f09e9245339951ffff13c87198f2e8aa35 Reviewed-by: Sérgio Martins <sergio.martins@kdab.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Fix separate_debug_info with unversioned_libnameAllan Sandfeld Jensen2015-07-081-1/+1
| | | | | | | | | | | | | | | | Handle unversioned_libname like plugins. Task-number: QTBUG-47065 Change-Id: I98469589416beb13f5beeff7273e84417fdbbfd5 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into devLiang Qi2015-07-016-14/+24
|\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qglobal.cpp src/corelib/global/qglobal.h src/corelib/global/qsysinfo.h src/corelib/global/qsystemdetection.h src/corelib/kernel/qobjectdefs.h src/plugins/plugins.pro tests/auto/widgets/itemviews/qlistview/qlistview.pro Change-Id: Ib55aa79d707c4c1453fb9d697f6cf92211ed665c
| * Merge remote-tracking branch 'origin/5.5.0' into 5.5Liang Qi2015-06-271-9/+10
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/cocoa/qcocoafiledialoghelper.h Manually fixed src/testlib/qtestcase.cpp to return the right type. Change-Id: Id1634dbe3d73fefe9431b9f5378846cb187624e4
| | * Use absolute rpath to Qt libraries for non-prefix buildsTor Arne Vestbø2015-06-041-9/+10
| | | | | | | | | | | | | | | | | | Task-number: QTBUG-46391 Change-Id: Iaebba29c340fb027e23a0923f3692d47f9d450d5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
| * | Disable gold linker/new dtags support for host buildsPeter Seiderer2015-06-101-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no test for gold linker and new dtags support for the host build (only for the target compiler/build) which leads to trouble in some cross compiling environments (see [1] for details). So disable gold linker/new dtags support unconditionally for host builds. [1] http://lists.busybox.net/pipermail/buildroot/2015-May/128303.html Task-number: QTBUG-46125 Change-Id: Ic62828704dcce461487d63860705158cce3e4af8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
| * | embed a VERSIONINFO resource into QML pluginsJoerg Bornemann2015-06-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, we set VERSION for QML plugins, because this embeds a VERSIONINFO resource into the DLL that can be inspected by the user. Change-Id: Ifb42efed6ceee05d05f61a271e028776cac6a3a2 Task-number: QTBUG-46473 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
| * | fix usage of wince scopeOswald Buddenhagen2015-06-053-3/+3
| |/ | | | | | | | | | | | | Fix style issues along the way. Change-Id: Ic6a6de28e198eb0b14c198b802e78845703909b9 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | fix "install target not created" for WinRt buildsJoerg Bornemann2015-06-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3ce99adf replaced DEPLOYMENT with INSTALLS and introduced the "install target not created" warning when running qmake on WinRt projects. The code path in qt.prf that was responsible for filling the DEPLOYMENT variable was never functional in Qt5. We're turning the code path off until this is properly fixed. Change-Id: If836ef648f9fb601b7597d39e3d00665d4cf01b0 Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Merge "Merge remote-tracking branch 'origin/5.5' into dev" into refs/staging/devSimon Hausmann2015-06-049-16/+39
|\ \
| * | Merge remote-tracking branch 'origin/5.5' into devSimon Hausmann2015-06-039-16/+39
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qnamespace.qdoc src/corelib/io/qwindowspipereader.cpp src/corelib/io/qwindowspipereader_p.h src/corelib/statemachine/qstatemachine.cpp src/corelib/statemachine/qstatemachine_p.h src/plugins/platforms/xcb/qxcbconnection.h tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/auto/tools/qmake/tst_qmake.cpp tests/manual/touch/main.cpp Change-Id: I917d694890e79ee3da7d65134b5b085e23e0dd62
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 22:49:59 +0000