summaryrefslogtreecommitdiffstats
path: root/qmake/generators
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove superfluous code from collectDependenciesJoerg Bornemann2015-12-041-5/+3
| | | | | | | val.first was never used. Change-Id: I7be631c09061d6969234502fc0d5660c147aca39 Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com>
* vcproj generator: Fix auto-generated inter-project dependenciesJoerg Bornemann2015-12-041-1/+1
| | | | | | Task-number: QTBUG-49580 Change-Id: I356be24ac555ed436e4f638e83c6cca703281cba Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* qmake: Correctly handle shadow build of nested vcsubdirs projects.Mathew Sutcliffe2015-12-011-21/+3
| | | | | | | | | | | | | | | For some reason, the solution generator was looking for the vcproj files in the source tree. It should look for them in the output tree instead (suggested by Joerg Bornemann). This should handle both in-source and out-of-source builds, and the special-case code for handling out-of-source builds (which had a bug) can be removed. Task-number: QTBUG-49665 Change-Id: I40b5c5907c52ffb074ccb8f297bb5924eacc1cb0 Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* Simplify a search for terminator.Edward Welbourne2015-11-241-7/+4
| | | | | | | | | We need to remember where the included file's name starts anyway; if we move this to before the search for the end, we don't need a separate variable to keep track of its length. Change-Id: Ia8d72839ac3fa32f2e748a21ee70dcab614562f4 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Comment to point out problem with CRLF handling.Edward Welbourne2015-11-201-0/+1
| | | | | Change-Id: I6352c5c68183207b9dfd332fbecc89c1c8c16d20 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Simplify a loop's set-up and control.Edward Welbourne2015-11-201-2/+2
| | | | | Change-Id: Ie9e002d7d7fb269f3a99cce98e4250a866523360 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Rework scan for keyword in preprocessor directive.Edward Welbourne2015-11-201-15/+11
| | | | | | | | | | | | | | | | | | When looking for the keyword in a preprocessor directive, we were checking for non-word characters to find its end. If that check failed (i.e. we had a word character) we would then check for EOL (which necessarily failed, on a word character). That made no sense. However, we genuinely have no interest in a directive with nothing after the keyword, so do check for EOL after the loop (once we've skipped spaces after the keyword). The loop itself was made needlessly complicated by, on finding the end of the keyword, skipping over later space inside the loop. Moved this outside the loop. Change-Id: Iccc2d445bf44deb75604e7fa60f2464e7397d8ed Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Skip spaces (after #) earlier to catch blank line or end-of-buffer.Edward Welbourne2015-11-201-8/+12
| | | | | | | | The C preprocessor does believe in a # [nothing] line; and we may as well give up before checking for keywords if we've run out of buffer. Change-Id: I64dc3ad2808435389d0d7b56dcbc9d92ae72aa6e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Avoid having division caught up in parsing of comments.Edward Welbourne2015-11-201-14/+13
| | | | | | | | | | | | | | | | | | A loop to skip space and comments was meant to break on anything else but would have not broken on a division operator (where it should) due to it getting caught in the check for a comment-start, without falling back suitably when it didn't complete that check. Managed to contrive a suitably twisted change to findDeps test to reveal the bug; broken previously, now fixed. Not ideal, as it relied on another bug to fail previously - backslash-newline shouldn't end a preprocessing directive line - but it should still pass once that's fixed, too. Exercising a bug in qmake usually involves code that won't compile anyway, making it tricky to write a test that reveals the bug but that passes once it's fixed. Change-Id: I08a1d7cc5e3d7fd1ac0a48e5c09dfdfbb7580b11 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Readability clean-up (purely cosmetic).Edward Welbourne2015-11-201-93/+97
| | | | | | | | | Principally *(buffer + expr) -> buffer[expr] changes, with some hspace normalization on affected lines. Made some empty loops more visible. Pulled out a repeated character class test as a function. Change-Id: I03d1b633550ad1814fa383d69ea04138dd0f82cd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Rip out the #qmake_warning "preprocessor directive".Edward Welbourne2015-11-201-17/+1
| | | | | | | | | | | | | | No-one is known to use it - we don't even have a test for it. It plays poorly with the real preprocessor and it has not produced any output since at least Qt 4.0 (unless qmake is invoked with at least one -d flag, drowning the output in level 1 debug output). This incidentally means no preprocessor directive we care about has an underscore in its keyword. Task-number: QTBUG-49487 Change-Id: I123a945c1dfe29d1d3ceee1129cfedc043f2e7d4 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* MakefileGenerator::processSources() doesn't need to be virtual.Edward Welbourne2015-11-132-2/+1
| | | | | | | | Only VcprojGenerator over-rode it; and did so with a replacement identical to the one on the base, so there was no point to it. Change-Id: I5b899372247809c82b1cae25817e06c5849cd10d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Xcode generator: only replace the suffix in the library pathRichard Moe Gustavsen2015-11-091-2/+9
| | | | | | | | | | | | | | | | | | | | The Xcode generator iterates trought all libraries and replaces their suffix (e.g "_debug") with a placeholder that lets Xcode switch between different library versions depending on the target. The current way we do this fails when the name of a library happens to contain the string "_debug" (e.g "qmldbg_debugger"). Since we replace every occurrence of suffix in the path, we end up replacing that part as well. The result will be linking errors. This patch ensures that we only replace the last occurrence of the suffix in the file path. Task-number: QTBUG-48961 Change-Id: I9fafbe0ea0ad8b9cfd13448d6b28801106e645ec Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* fix vcxproj linker optionsJoerg Bornemann2015-10-271-6/+7
| | | | | | | | | | Commit 4bb004de94380304d8950e860d1823975927ec59 broke the linker options in generated Visual Studio projects. We need to call fixLibFlags on QMAKE_LIBS and QMAKE_LIBS_PRIVATE. Task-number: QTBUG-48936 Change-Id: I2f12bf0117d27104cd34f2f43fdeb7b948fa375e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-231-0/+2
|\ | | | | | | | | | | | | | | Conflicts: src/corelib/kernel/qcfsocketnotifier.cpp src/tools/qdoc/qdocindexfiles.cpp Change-Id: Iae365b23afc611de8794f22cceae8b210d25aa8a
| * Add support for -Zc:throwingNew option to vcxproj generation for 2015Andy Shaw2015-10-231-0/+2
| | | | | | | | | | | | | | Task-number: QTBUG-48898 Change-Id: I56abae0cbc56e07fd9bb554b84927c327c1b3232 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
* | support relative paths in QMAKE_RPATHDIROswald Buddenhagen2015-10-201-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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>
* | fix bogus complaints about prl targets without extension in bundlesOswald Buddenhagen2015-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | the library inside a bundle doesn't have an extension. this doesn't really fix anything except suppressing the error message, as we discard the result of the operation anyway. Change-Id: Idfe3d1714dedb59d9d3e86a65f074e516c431389 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | fix the trailing-backslash-in-DESTDIR-on-mingw workaroundOswald Buddenhagen2015-10-141-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | at least the mingw version we use now interprets the sequence \# as a literal hashmark, which completely defeats the previous hack. the new hack escapes the backslash with another backslash, which appears to work. however, make does *not* remove the additional backslash, so the result is a bit ugly. Change-Id: I591a2be443880b162094d04e5a5e624216b59311 Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
* | QtCore/qmake: drop some unneeded QChar -> QString conversionsMarc Mutz2015-10-111-1/+1
| | | | | | | | | | Change-Id: Id2fb5089b0ec51073efb846b59ecc63942cfb60d Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* | Stop generating implicit suffix rules in MakefilesTor Arne Vestbø2015-10-093-22/+2
| | | | | | | | | | | | | | | | | | | | | | | | Suffix rules are the old-fashioned way of defining implicit rules for make. We don't need them as we generate explicit rules for all sources we build. [ChangeLog][qmake] Makefile output no longer contains implicit suffix rules, as all sources are built using explicit rules. Change-Id: I4ecfa5b80c8ae33aea8730836f3baf99dd4951dd Task-number: QTBUG-30813 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | Distinguish between Objective-C and Objective-C++ sourcesTor Arne Vestbø2015-10-094-120/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-022-12/+14
|\ \
| * | Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-022-12/+14
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * qmake: Fix 'Libs:' line in .pc files on OS XMartin Afanasjew2015-09-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On OS X with a framework-based build of Qt, the 'Libs:' line of the .pc files generated by `qmake` references the framework. This requires two separate arguments to the linker: The fixed string '-framework' and the name of the framework (e.g. 'QtCore'). Only the latter might need quoting. Prior to this fix, they were treated as a single argument (e.g. '-framework QtCore'), thus always quoted because of the contained space, and later lead to errors when trying to link a Qt framework discovered via `pkg-config`. Change-Id: I5c11ee651048832007e2ee4ebcbcf2e3212c8f48 Task-number: QTBUG-47162 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
| | * fix parsing of WinRT compiler optionsJoerg Bornemann2015-09-181-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set defaults before parsing compiler options. UsePrecompiledHeader, CompileAsWinRT and GenerateWindowsMetadata options were overwritten after parsing the options. Task-number: QTBUG-46978 Change-Id: I8c4e423cd13f575fa679b114108b693937908549 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
| | * Fix qmake messing up headers of generated Visual Studio solution filesJonathan Meier2015-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While generating Visual Studio 2015 solution files for a project using the subdirs template qmake writes out both the header for version 2015 and version 2013. The problem is a case fall-through. Task-number: QTBUG-48110 Change-Id: Ib6ddc1ceb306be9b3098d7b7c66a8ffabbd86481 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com> Reviewed-by: Andrew Knight <andrew.knight@intopalo.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | | merge MingwMakefileGenerator::findLibraries() into Win32MakefileGeneratorOswald Buddenhagen2015-10-028-115/+86
| | | | | | | | | | | | | | | | | | | | | | | | 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-025-71/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | make .prl processing less convolutedOswald Buddenhagen2015-10-022-53/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | don't look up the files and normalize the paths multiple times, as this is inefficient and hard to understand. on the way, processPrlFile() got unnested, and libExists() got nuked. note that a missing QMAKE_PRL_TARGET will be now complained about, which really should never happen. Change-Id: Ibcd77a7f963204c013548496ecd2d635e1a4baba Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | | make processPrlFile() munge the path less when replacing the targetOswald Buddenhagen2015-10-021-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | don't prepend the normalized path to the target name, but replace only the filename in the original string. this ensures that any variables in the path are preserved. Change-Id: I58c2b54b7114bfdbf659e6a6ce3e02c2611900d4 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | | make lflags deduplication independent from link_prlOswald Buddenhagen2015-10-021-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the dependency doesn't seem to make any sense. while the deduplication is a bit naive and thus dangerous, it was already enabled by default anyway by virtue of link_prl being enabled by default, so this amounts to a non-change for by far most projects. use no_lflags_merge to disable it. Change-Id: Ia441931ddbc41ed617aee21e6fe8821e3448d2bc Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | | merge processPrlFiles() into findLibraries()Oswald Buddenhagen2015-10-028-161/+121
|/ / | | | | | | | | | | | | | | 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-013-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 support for CONFIG+=compile_libtoolOswald Buddenhagen2015-10-012-100/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | "why not use libtool?" -- sam "srsly dude?!" -- ossi [ChangeLog][qmake] Support for CONFIG+=compile_libtool was removed. Use CONFIG+=create_libtool and/or custom compilers instead. in addition to its utter insanity and superfluousness, this feature was apparently quite broken anyway (QTBUG-35745). Change-Id: I8147a2953f5f065735ae3a2206cd5d33a7c1809a Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove questionable libtool "compatibility" code from prl processingOswald Buddenhagen2015-10-011-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this code would get enabled when *not* compiling with libtool, and would try to use the real library in .libs/ when one tried to link the .la file (i.e., it would reproduce libtool's functionality). that directory structure is found only in build directories, so this code was apparently meant to support mixed projects. that doesn't sound useful. on top of that, the other code paths that were supposed to treat .la files like .prl files were disabled before initial release (because Somebody (TM) noticed that their code "doesn't behave well"). this code here did the same thing, but at the wrong abstraction level. as a side effect, this removes an infinite recursion problem in that code. Task-number: QTBUG-46910 Change-Id: If5291f5ff42c1412075c195753162c54598a250e Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove pointless code pathOswald Buddenhagen2015-10-011-11/+3
| | | | | | | | | | | | | | | | | | there is no need to consider the "-framework foo" syntax, as we fully control the list and insert elements exclusively as "-framework" "foo" a few lines down. Change-Id: I95fa8b46f53673ea3df1a67a2a44d11f7d679cc6 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove pointless code from prl processingOswald Buddenhagen2015-10-011-13/+1
| | | | | | | | | | | | | | the code had a dead variable assignment and no side effects. Change-Id: I9add8f1776f23a29c103b46dc725b9f386a4495a Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove bizarre prl substitution codeOswald Buddenhagen2015-10-011-9/+1
| | | | | | | | | | | | | | | | | | it appears to have been some weird attempt at back-mapping file names to -l arguments, which has been made ineffective with the partial #if 0. i can't even describe what it did at this point. Change-Id: Ie31cbbe7fab8b21b039bfff5877397af07731f1b Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | make /LIBPATH: deduplication code more like in the unix generatorOswald Buddenhagen2015-10-011-18/+13
| | | | | | | | | | Change-Id: If7e83a46b1a2ad92723a222daffa687d74636858 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove link_highest_lib_version misfeatureOswald Buddenhagen2015-10-013-24/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* | remove magic patching up of libraries specified by file nameOswald Buddenhagen2015-10-012-82/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the assumption is that if somebody bothers to actually specify a file name, they'll most probably go all the way to specify the *correct* file name. otherwise, they'll use -L/-l flags to specify the libs in a cross-platform way and rely on qmake's magic. this code was initially added for the purpose of invoking findHighestVersion() under windows. this has been off by default for a while now. at some point, the code did also swap qt for qt-mt and vice versa if the specified one was missing. this is obviously gone for a while as well. the unix code was pretty much broken since day one: there was a regex match on lib<stub>.* against <stub> itself, which obviously could not have ever succeeded. consequently, the subsequent code ran into a path that tried the file name with a trailing dot (instead of a new extension), which never produced anything meaningful. [ChangeLog][qmake][Important Behavior Changes] The library lookup has been simplified. It may be necessary to be more explicit in some edge cases now. Change-Id: I5804943f1f7a16d38932b31675caabbda33eada7 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | unify handling of library prefixes and extensionsOswald Buddenhagen2015-10-015-30/+5
| | | | | | | | | | | | | | | | | | | | | | 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 references to $$QMAKE_CYGWIN_EXEOswald Buddenhagen2015-10-011-2/+0
| | | | | | | | | | | | | | | | | | it would cause the unix generator to set TARGET_EXT, but that wasn't used anywhere. so remove the dead code. if it ever gets re-introduced, it will be as QMAKE_EXTENSION_EXE. Change-Id: I44ce3e612651fd229177e37ab6c8879cd8c474b7 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | inline NmakeMakefileGenerator::getPdbTarget()Oswald Buddenhagen2015-10-012-7/+1
| | | | | | | | | | | | | | it was used only once, and virtual for no reason whatsoever. Change-Id: I99411be3dac93d8a129441f656b2443d09108564 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | remove support for {rvct,arm,ti}_linkerOswald Buddenhagen2015-10-012-61/+12
| | | | | | | | | | | | | | | | 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>
* | remove overuse of trimmed()Oswald Buddenhagen2015-10-014-10/+9
| | | | | | | | | | | | | | | | there is no reason to expect the various list elements to be space-encumbered, or to tolerate it if they were. Change-Id: I1a2e5c8d30456b640408503334c55f9262792db5 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | de-duplicate calculation of target baseOswald Buddenhagen2015-10-011-6/+7
| | | | | | | | | | Change-Id: I546fe454f925dd9ad39ba444fa78455c8dbdfde6 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | don't support arbitrary flags in LIBS on windowsOswald Buddenhagen2015-10-011-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | there should be no flags other than /LIBPATH: in LIBS (and the variables that end up in it) - these belong into QMAKE_LFLAGS. while not very important, this change enables the use of drive-relative paths using unix path separators. note that on unix, arbitrary flags must be supported in LIBS due to GNU ld's --push-state and related position-dependent flags (-whole-archive in particular). luckily, on unix, flags start with a dash, not a slash. Started-by: Dyami Caliri <dyami@dragonframe.com> Change-Id: Ie5764f14d34ad13020ca010499594eed8c69a4a1 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | fix race in debug_and_release builds of static libs for UnixJoerg Bornemann2015-09-221-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a debug_and_release build of a static library. Set DESTDIR to different values for debug/release. Let TARGET be the same for debug/release. Now qmake would generate code in Unix Makefiles like this: rm mylib.a ar mylib.a ...objects... rm debug/mylib.a mv mylib.a debug/mylib.a and for release analogous. This clashes when building in parallel. This patch resolves this conflict by reducing the commands to: rm debug/mylib.a ar debug/mylib.a ...objects... We believe that every ar implementation that's in use for Qt is able to operate on files in subdirectories. [ChangeLog][Important Behavior Changes][qmake][Unix] QMAKE_POST_LINK steps of static libraries are now required to operate on $(TARGET) in $(DESTDIR) instead of $$OUT_PWD. This matches the Windows backends. Task-number: QTBUG-48287 Change-Id: I192f488ed74c56bc32862426d9e9d4237d9b8135 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 10:14:38 +0000