summaryrefslogtreecommitdiffstats
path: root/qmake/generators/win32/mingw_make.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Port from container::count() and length() to size() - V5Marc Mutz2022-11-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to handle typedefs and accesses through pointers, too: const std::string o = "object"; auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); }; auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) { auto exprOfDeclaredType = [&](auto decl) { return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o); }; return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes)))); }; auto renameMethod = [&] (ArrayRef<StringRef> classes, StringRef from, StringRef to) { return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)), callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))), changeTo(cat(access(o, cat(to)), "()")), cat("use '", to, "' instead of '", from, "'")); }; renameMethod(<classes>, "count", "size"); renameMethod(<classes>, "length", "size"); except that the on() matcher has been replaced by one that doesn't ignoreParens(). a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'. Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache, to avoid porting calls that explicitly test count(). Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-1/+1
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-27/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* qmake: Fix overlong command lines for static Qt builds on WindowsJoerg Bornemann2022-02-211-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linker response files for the MinGW and Unix makefile generators are controlled by the variable QMAKE_LINK_OBJECT_MAX. This variable holds a number. If the number of object files passed to the linker exceeds this number, a linker response file containing object file paths is created. This heuristic is extremely imprecise. It doesn't take into account the length of object file names nor the length of $$OBJECTS_DIR. Also, when using a static Qt, a big part of the linker command line are libraries. A relatively small example can fail to link with "The command line is too long" on Windows, even with the object files being in a response file. The MinGW makefile generator already reads the variable QMAKE_RESPONSEFILE_THRESHOLD for compiler response files. Re-use this variable for the linker response file of the Unix and MinGW makefile generators. If QMAKE_RESPONSEFILE_THRESHOLD is set, use it to determine whether to create a response file. QMAKE_LINK_OBJECT_MAX is then ignored. The response file contains objects and libraries. If QMAKE_RESPONSEFILE_THRESHOLD is not set, use QMAKE_LINK_OBJECT_MAX to determine whether to create a response file. The response file contains only object files. QMAKE_LINK_OBJECT_SCRIPT is used in both cases to specify a common base name of all linker response files. Pick-to: 6.2 6.3 Task-number: QTBUG-100559 Change-Id: I3c78354fa5ebb1a86438ec804679e0ee776c3f49 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* MinGW: Use a response file for long include pathsOrgad Shaneh2020-07-061-4/+19
| | | | | Change-Id: I55ce73ad08473bca27c7ab5730f633fb77c9b8cd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Makefile: Deduplicate logic for response file nameOrgad Shaneh2020-07-061-13/+4
| | | | | | | + verify that the file was actually written. Change-Id: I14a3c0b75f41f926b469109a1d7f2f80368ec9bb Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qmake: Stop using -isystem flagDmitry Shachnev2020-06-061-6/+1
| | | | | | | | | | | This option changes the order of include paths, which can cause problems of various kinds. See https://bugs.debian.org/958479 for an example. The benefit of that option is minimal for what it was intended. Pick-to: 5.15 5.12 Change-Id: I80eeabd09764df290b60bc59aeb2f90d07723608 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port qmake from QStringRef to QStringViewLars Knoll2020-06-051-4/+4
| | | | | | Change-Id: Ie07a976cd3c634e04c8b9b1e0a6cacd4c2d94939 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qmake: Fix handling of manifest file of msvcYuhang Zhao2020-05-111-5/+0
| | | | | | | | | | | | | Setting the QMAKE_MANIFEST variable doesn't have any effect for MSVC. This commit fixes that. If the developer is setting this variable, he/she will definitely use CONFIG-=embed_manifest_exe or CONFIG-=embed_manifest_dll at the same time, so I think there is no need to check this. Change-Id: Ie32b7e0cded71efcf14bf4c0eecab5ab1944fa2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Port qmake over to user QRegularExpressionLars Knoll2020-05-051-2/+2
| | | | | | | | | Use the DotMatchesEverythingOption for all places where we interpret .pro files, to increase compatibility with QRegExp. Change-Id: I347d6b17858069f3c9cedcedd04df58358d83f27 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Be able to create a response file for other generators tooAndy Shaw2019-11-061-24/+0
| | | | | | | | | | | | When building an application for Android on Windows it is possible that the command line will be too long when doing the link step. So the code for generating a response file is moved to MakefileGenerator so it can be used by the other generators easily. The same variables used by MinGW can be used elsewhere then. Fixes: QTBUG-71940 Change-Id: I6c331d12e9541a90a4a95e0154d0ea1c056489bc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Determine dependencies of Windows resource filesJoerg Bornemann2019-08-131-1/+5
| | | | | | | | | | | | | | | | Windows resource files support a subset of C preprocessor directives. Among others they can have #include directives. Use QMake's own scanner to retrieve the files that are included by a Windows resource file and add them to its dependencies. For the test case the TestCompiler class had to be extended: runCommand is now public, and commandOutput is less peculiar. Fixes: QTBUG-3859 Change-Id: I138703352c37c98297c0574a9a440510c1c494b8 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Remove QMake's -createstub optionJoerg Bornemann2019-08-031-12/+0
| | | | | | | | | This undocumented option was introduced in 69c22301806b56d56cbe5f5076b889ba98e41a2b (old internal history, 2006) to prepare some unspecified change to configure that was never done. Change-Id: I60de731ac9bc6f6424c57574e59e9f6b4f6c5eb3 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-07-301-27/+9
|\ | | | | | | | | | | | | Conflicts: qmake/generators/win32/mingw_make.cpp Change-Id: I2f790bc8572bd22fea01edf7ca74595b29f063eb
| * qmake: Use a simple response file for ar on mingwOrgad Shaneh2019-07-291-27/+9
| | | | | | | | | | | | | | | | | | | | | | This change allows using custom flags for ar. For instance, it is now possible to create a thin archive by setting QMAKE_LIB += -T. This uses and extends commit d92c25b1b4ac0423a824715a08b2db2def4b6e25 which served a similar purpose for the linker. Change-Id: Ie1d6a0b957dc4809957726de00911c8d91647fab Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-06-271-1/+1
|\| | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/network/ssl/qsslsocket_openssl.cpp Done-With: Timur Pocheptsov <timur.pocheptsov@qt.io> Change-Id: Ibb57a0548b4977797b400637487a56245ac1c024
| * Fix 'clean' target for MinGW DLLsJoerg Bornemann2019-06-241-1/+1
| | | | | | | | | | | | | | | | | | | | 'make clean' removed the import libs for DLLs which makes them quite unusable. Move the import lib removal to the 'distclean' target. Fixes: QTBUG-51977 Change-Id: I727d520435f88a83a7fb14cb0ad81f8fe7c6d61b Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | Clean up class definitions of makefile generatorsJoerg Bornemann2019-05-161-4/+0
| | | | | | | | | | | | | | Remove pointless constructors and destructors. Change-Id: I7aea8587bf3598b6f5324aac8898edf227475d63 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* | Prefix textstream operators with Qt::Lars Knoll2019-05-021-12/+12
|/ | | | | | | As the non prefixed variants are deprecated Change-Id: I2ba09d71b9cea5203b54297a3f2332e6d44fedcf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* qmake: make sure QMAKE_LIBS{,_PRIVATE} comes after LIBS{,_PRIVATE}Oswald Buddenhagen2018-10-121-1/+3
| | | | | | | | | | the early merging of LIBS* into QMAKE_LIBS* meant that we could not interleave them properly. defer the merging until the points of use. Task-number: QTBUG-70779 Started-by: BogDan Vatra <bogdan@kdab.com> Change-Id: I890f98016c3721396a1f0f6f149a9e2b37d56d8e Reviewed-by: Liang Qi <liang.qi@qt.io>
* qmake: Fix building with lld with mingw makefilesMartin Storsjö2018-10-121-15/+17
| | | | | | | | | | | lld for coff/mingw doesn't support linker scripts, which qmake used for passing larger numbers of input file names to the linker. Instead of using a fullblown linker script for this, just use a plain response file, which both lld and binutils ld support. Change-Id: I3aace7902fa6ca861a0a9fe67feaa236e7ea417b Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qmake: rework .prl filename constructionOswald Buddenhagen2018-08-301-2/+0
| | | | | | | | | | | instead of trying to reverse-engineer it from the final target including extension and possible bundle path, construct the basename explicitly. this avoids that we mangle the filename if the actual target contains a period for some reason. Task-number: QTBUG-70097 Change-Id: I0bae9f010ab82e258680830250f8e28656f09d67 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qmake: get rid of (some) makefile expansions in dependency pathsOswald Buddenhagen2018-07-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the variables are quoted correctly for commands, which is incompatible with quoting for dependencies under mingw. so insert the paths as literals, where we can control quoting. this fixes building in directories with spaces, which i broke in 7c34e0a7b by using different quoting styles for deps and commands in the first place. this breaks the hypothetical use case where somebody wants to override TARGET or DESTDIR (or DESTDIR_TARGET under windows) on the *make* command line. not sure why anyone would do that - just do it at the *qmake* level. we did not get rid of OBJECTS, because that would cause significant duplication in the makefile (not that it would matter too much, given the dependency lists ...). this isn't a problem, because these are short relative paths which are not expected to contain "funny" characters. an alternative would have been to change the variables' quoting and eliminate them from the commands instead, but that would be backwards-incompatible, because commands are "user-servicable". for the same reason, we cannot get rid of the variables entirely. Change-Id: Ic7592c7fc67d8b7d2b64de80808365cd1c3f79d0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qmake: fix lookup of .prl files for libs specified by full filenameOswald Buddenhagen2018-07-161-0/+13
| | | | | | | | | | | | | | | | | | | under windows, libraries can have a numeric suffix derived from VERSION, and (under MinGW) a unix-like "lib" prefix - neither of which .prl files have. therefore, we had to make the back-mapping from the library to the .prl file reverse-engineer the original TARGET's name. we verify whether we actually got the right file by comparing the target specified inside the .prl file with what we started from. this fixes linking of transitive deps of static deps. the alternative of changing the .prl naming pattern to avoid the back-mapping was discarded, as a) it would be backwards incompatible and b) it would break project-internal -lfoo references to versioned libs. Change-Id: Ia9b899fe6a5700fee528bd1dacf130caf083cdd6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qmake: escape colons and hashmarks in dependency pathsOswald Buddenhagen2018-06-251-2/+1
| | | | | | | | | | | | | | | | | | | these characters can appear in file names, but are meta characters in dependency context. they have different semantics in make commands, so this required some reshuffling in the windows generator (which just treated dependencies and commands the same way). we don't actually escape colons for nmake, because it has magic treatment of drive letters anyway (and colons cannot appear elsewhere). also, if a target's filename gets quoted, batch rules will blow up. therefore, "funny" file names are really only supported as inputs - which is just enough to make resource embedding work. Task-number: QTBUG-22863 Task-number: QTBUG-68635 Change-Id: I473b0bf47d045298fd2ae481a29de603a3c1be30 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qmake: use consistent path separators in makefile dependenciesOswald Buddenhagen2018-06-121-2/+2
| | | | | | | Task-number: QTBUG-65072 Change-Id: I3456d9b2cdfa9c65be5933f592abb640f81c39f2 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qmake: Handle QMAKE_LINK_OBJECT_MAX being unset for static librariesMartin Storsjö2018-01-041-1/+2
| | | | | | | | This was missed in 8bebded9. Task-number: QTBUG-63637 Change-Id: I6be472430a9aa8f533def4fd6c14c8dbfe8b6f70 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qmake: Actually resolve QMAKE_SHELL_NULL_DEVICE when writing to MakefileOrgad Shaneh2017-10-161-1/+1
| | | | | | | This is C++, not qmake code. Amends 5fa6438633. Change-Id: Ie5b88c3a06dbe089948488ea3b4b297a08164113 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Qmake: Introduce and use QMAKE_{SYSTEM,SHELL}_NULL_DEVICE variable, take 2Orgad Shaneh2017-10-131-7/+1
| | | | | | | | | | SYSTEM is used for system() calls, while SHELL is used in the target Makefiles. Task-number: QTBUG-62985 Change-Id: Ia75d3939c59c98699359421166433e8b4a6ee35e Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qmake: don't limit command line length when not actually on windowsOswald Buddenhagen2017-08-151-1/+2
| | | | | | | | | | | | | QMAKE_LINK_OBJECT_MAX is actually a property of the host, not the target. this works around binutil's inability to use thin LTO objects in conjunction with an MRI script (https://sourceware.org/bugzilla/show_bug.cgi?id=21702). Task-number: QTBUG-61335 Change-Id: I90a1334b9c905c433b35546e8f3f3b5089d2c65b Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* qmake: Separate object_script by Makefile nameOrgad Shaneh2017-07-071-0/+4
| | | | | | | | | If several Makefiles are used in the same directory (for example, for multiple projects in the same directory or different build configurations), they all reference the same object_script, which is obviously wrong. Change-Id: I9b499ceb6b6bd6058f54b452fa44bfb2313eec26 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qmake: Delete static library before calling ar on MinGWOrgad Shaneh2017-06-121-0/+7
| | | | | | | | | | | | This was already done on unix, but not for MinGW. If the archive already exists, it is appended rather than replaced. This can cause invalid references when whole-archive linking is used and some object file that was already linked was deleted. Change-Id: Ie265371f197d996d57002b248043736544ee641e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* unbreak "aux" template for mingw & msvc, take 3Oswald Buddenhagen2016-12-071-3/+3
| | | | | | | | | | | | | | | | eliminating everying TARGET-related was a nice try, but in the real world (e.g., qttranslations), extra compilers are activated by PRE_TARGETDEPS, which of course doesn't work when TARGET is entirely gone. so instead, let it act as a phony target. this is consistent with the unix generator. supersedes 0810d48bc in amending af2847260. Task-number: QTBUG-57423 Change-Id: I3d2ecc4ff42b37ffe5f71f5c20d17c06b31f4da2 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-11-251-2/+7
|\ | | | | | | | | | | | | | | Conflicts: mkspecs/features/qml_module.prf src/corelib/tools/qdatetimeparser_p.h Change-Id: I5382cee3ddb33107dc61ee20f7a9188c4a68a882
| * unbreak "aux" template for mingw & msvc, take 2Oswald Buddenhagen2016-11-231-2/+7
| | | | | | | | | | | | | | | | | | | | | | of course, we should stub out everything related to TARGET - only the generic "all" and "first" targets including their deps should be emitted. amends af2847260. Change-Id: I8ed7a550b8022c69328d2e16dbd078928d176964 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-02-111-1/+1
|\| | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qfilesystemwatcher_win.cpp src/corelib/plugin/plugin.pri src/plugins/platforms/cocoa/qcocoaaccessibility.mm tests/auto/corelib/tools/qlocale/tst_qlocale.cpp Change-Id: Id6824631252609a75eff8b68792e4d10095c8fc1
| * qmake: use QString::replace() overloaded with QLatin1StringAnton Kudryavtsev2016-02-041-1/+1
| | | | | | | | | | | | | | | | | | instead of QStringLiteral, QString, const char*. Results: reduce .rodata, prevent re-creation of QString. Change-Id: Ie2e3089974c42e6733457bbe58521bccd1da3a53 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-01-261-0/+12
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/android/jar/src/org/qtproject/qt5/android/QtActivityDelegate.java src/dbus/qdbusconnection_p.h src/dbus/qdbusintegrator.cpp src/dbus/qdbusintegrator_p.h tests/auto/corelib/io/qdir/qdir.pro tests/auto/corelib/io/qiodevice/tst_qiodevice.cpp Change-Id: I3d3fd07aed015c74b1f545f1327aa73d5f365fcc
| * Work around MinGW-make's magic prefixing of paths.Frederik Gladhorn2016-01-211-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building QNX on MS-Windows, make magically adds the Msys root as prefix to variables whose values look like paths; this applies to both environment variables and variables given values on the command-line. When we don't actually want to install under the Msys root, this is unwelcome "help". So (for MinGW's make) support a magic prefix of our own, @msyshack@, that'll make a path value for INSTALL_ROOT not look like a path to make; we can then strip it off when we come to use it. Change-Id: I951ad3c8fe3e5cfb49e6e361d7fff779f3a9d716 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
* | Updated license headersJani Heikkinen2016-01-211-17/+12
|/ | | | | | | | | | | | | From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some exceptions, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one (in those files which will be under GPL 3 with exceptions) Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* merge MingwMakefileGenerator::findLibraries() into Win32MakefileGeneratorOswald Buddenhagen2015-10-021-77/+12
| | | | | | | | as a side effect, this makes the extensions used for searching libraries configurable under windows (QMAKE_LIB_EXTENSIONS). Change-Id: I3e64304fcadbfe74d601b50a70a73180c894503e Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* rewrite windows library handlingOswald Buddenhagen2015-10-021-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | first, store the library's full name in the .prl file, like we do on unix. this is not expected to have any side effects, as QMAKE_PRL_TARGET was entirely unused under windows so far. then, rewrite the mingw library handling: instead of letting the linker resolve the actual libraries, do it ourselves like we do for msvc. we could not do that before due to the partial file names in the .prl files: if the library didn't exist at qmake execution time, we'd have to guess the file extension (the msvc generators never had that problem, as they know about only one possible extension for libraries anyway). make use of processPrlFile()'s ability to replace the reference to the .prl file with the actual library. that way we don't need to re-assemble the file name from pieces, which was fragile and inefficient. QMAKE_*_VERSION_OVERRIDE does not affect libraries coming with .prl files any more. additionally, it is now used literally (not numerically), and values less or equal to zero lost their special meaning as "none" - this isn't a problem, because that's the default anyway, and there is no need to override bogus versions from .prl files any more. no changelog for that, as i found no public traces of that feature outside qtbase. [ChangeLog][qmake][Windows] Libraries coming with .prl files can now have non-standard file extensions and a major version of zero. [ChangeLog][qmake][Windows][Important Behavior Changes] The .prl files written by earlier versions of Qt cannot be used any more. This will affect you if you depend on 3rd party libraries which come with .prl files. Patch up QMAKE_PRL_TARGET to contain the complete file name of the library, and replace any /LIBPATH: in QMAKE_PRL_LIBS with -L. (the part about /LIBPATH: actually refers to the next commit.) Change-Id: I07399341bff0609cb6db9660cbc62b141fb2ad96 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* merge processPrlFiles() into findLibraries()Oswald Buddenhagen2015-10-021-6/+34
| | | | | | | | seems pointless to tear apart the functions, on the way duplicating some boilerplate. Change-Id: Ide3697ca1c931e8de607ac48c21cecce4781fe13 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* remove QMAKE_<lib>_SUFFIX supportOswald Buddenhagen2015-10-011-2/+0
| | | | | | | | | | | | | this feature was added with a dubious commit message a decade ago, was undocumented, and there are no public traces of it being used. if i had to guess what it was meant for: to be able to consistently use -lfoo throughout a project and centrally (e.g., in .qmake.cache) choose to use foo<bar> (bar possibly being "d") instead. however, more explicit methods are being used instead, including in qt itself. Change-Id: Ic3a98dc3aec59876f26909fbf9f7aba32baa05bf Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* remove link_highest_lib_version misfeatureOswald Buddenhagen2015-10-011-1/+1
| | | | | | | | | | | in retrospect, we were too conservative in 925fd32a2d8f making the "feature" optional - it simply makes no sense to have qmake automatically find the highest major (!) version of a library based on a loosely defined platform-specific convention (not standard, unlike ELF's .so versioning) with side effects. Change-Id: Iba92df433b199a9fbff88358f6e0f6835f2e813d Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* unify handling of library prefixes and extensionsOswald Buddenhagen2015-10-011-7/+1
| | | | | | | | | | | 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>
* remove support for {rvct,arm,ti}_linkerOswald Buddenhagen2015-10-011-40/+8
| | | | | | | | rvct and armcc support are remnants from symbian, while the ti linker support was never completed in the first place. Change-Id: I5c9d7f0ce67de24c348cbee4af618a499fe06f16 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* Introduce qmake RC_DEFINES for RC preprocessor definesM. Moellney2015-06-021-1/+6
| | | | | | | | | | | | | | | | | | qmake win32 generators by default used values of DEFINES for RC preprocessor defines, too. For simple defines this works. For string literals this failed for the .vcxproj files: DEFINES += "FOO=\"BAR BAR\"" works for CL but fails for RC. DEFINES += "FOO=\\\"BAR BAR\\\"" works for RC but fails for CL. This patch introduces the qmake variable RC_DEFINES. The variable contains the preprocessor defines, that are used for RC. If the varible is not set, the DEFINES values are used for RC. Task-number: QTBUG-44184 Change-Id: I4202271759d29de8c1829347ae3ef117eda54b38 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* centralize setup of shell-related variables in spec_post.prfOswald Buddenhagen2015-03-061-10/+0
| | | | | | | | | | | | | | | | | | it makes no sense to let every spec do that separately, as it's fixed by the generator+shell. putting it into a file which is loaded regardless of the spec also allows us to remove the hardcoded fallbacks from qmake. if somebody overrode the values in their spec for some weird reasons, they'll need to override spec_post.prf. shell-{unix,win32}.conf are now dummies and print warnings. Task-number: QTBUG-37269 Change-Id: I66c24fb4072ce4d63fdbfc57618daa2a48fa1d80 Reviewed-by: Jochen Seemann <seemann.jochen@gmail.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* replace incorrect uses of fixPathToLocalOS() (mostly)Oswald Buddenhagen2015-02-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | in most cases, it actually means normalizePath() (because the file name is used with qt i/o functions afterwards). this affects QMakeLocalFile::local() as well, so many not immediately obvious places are affected as well. there was also one case of fixPathToTargetOS() falling into this category. this is mostly a no-op, as the qt functions are agnostic to the path separator. in some other cases (in particular in the vcproj generator), it actually means fixPathToTargetOS(). this is mostly a no-op as well, as the two functions are equal except on msys anyway. in the <meta file>FileName() functions, the use of a fixPath*() function is bogus in the first place - fileFixify() already does fixPathToTargetOS(), and this is correct when the file name is used verbatim in a make command (which it is). otherwise it's irrelevant. Change-Id: I26712da8f888c704f8b7f42dbe24c941b6ad031d Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 14:53:22 +0000