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>
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>
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>
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>
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>
seems pointless to tear apart the functions, on the way duplicating some
boilerplate.
Change-Id: Ide3697ca1c931e8de607ac48c21cecce4781fe13
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
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>
in retrospect, we were too conservative in 925fd32a2d 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>
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>
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>
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>
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>
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>
they are self-contained, as they are the result of another project's
full resolution. consequently, recursing them just burns cycles, and
additionally introduces the risk of an endless loop if the file is
botched.
Task-number: QTBUG-12711
Change-Id: I401ee691c170092cc61fe05538cec4272ed8f922
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
we use qmake properties in the installed .prl files, so the paths
need to be converted to native separators before emission.
Task-number: QTBUG-46217
Change-Id: If3fb0a84488795478fc2a701271c931c62eba6aa
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
don't try to install the primary target, as it obviously doesn't exist.
however, we must not disarm bundle installation.
Change-Id: I3074150f749220d77c1210a4978e71aff9c9a3a9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
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>
we strip the path a few lines above already.
Change-Id: If7524b8e744d2f1ab2f5a6920097d25671449829
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it makes no sense to call it on paths that are fixified right before or
after, as fileFixify() calls it itself.
and verifyExtraCompiler() calls normalizePath() on its file argument.
Change-Id: I8fb21e129fd29428d1855de73483087842bc1bdd
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
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>
instead of quoting more or less random variable contents early,
consistently quote everything only right before it is needed. this way
we can be sure that everything is correctly quoted, but not over-quoted.
this removed the need for the insanity that unescapeFilePath() and
similar ad-hoc contraptions were.
this had the somewhat counter-intuitive effect that it was possible to
remove escapeFilePath() calls from PBX::writeSettings() calls - these
were actually only unescaping.
[ChangeLog][qmake][Important Behavior Changes] A lot of quoting issues
have been fixed. As a side effect, qmake has become more sensitive to
over-quoted file names in project files.
(*) ok, maybe not. close enough.
Task-number: fatal: out of memory
Change-Id: I8c51cfffb59ccd156b46bd5c56754c480667443a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
it makes no sense to test for OBJECTS_DIR emptiness when we are going to
use DESTDIR instead.
Change-Id: I0f7115fc8a9fe2a996417d5f50bd0165773129fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
that makes no sense at all. and OBJECTS_DIR is not resolved, either.
Change-Id: Ie76b9de6bb11ae42945255f2e168943066d2f60d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
MakefileGenerator::init() fixifies the variable, so there is no point in
the windows generator adjusting path separators as well.
Change-Id: I9331631125ee16ce4d64e38153f3c67f2f78b16b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this is admittedly a rather improbable use case, so unlikely to have any
real world effect.
Change-Id: If98f0de90043525f0555f8ddf98f8b4352e5a0a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
commands come already fully expanded and quoted from the project.
Change-Id: I239d5c305f5f65d32c832bc09bfd1c322051e149
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
instead of having each generator do its own magic (little surprisingly,
with different outcomes), add "stuff" to the search path in one place
used by all generators. this has several consequences:
- (unless disabled via CONFIG+=no_include_pwd) $$PWD is now consistently
prepended by all generators. most notably, this was entirely missing
from the MSVC generators (both nmake and VS) - despite them needing it
most. this also affects Xcode projects.
- $$OUT_PWD (if different from $$PWD) is now added right after $$PWD,
not at the end. this precedence clarification only makes sense, given
that qmake tries to make shadow builds as transparent as possible.
- the qmakespec's dir is now consistently appended. the UNIX and PBX
generators prepended it, while the rest already appended. few files
actually include qplatformdefs.h, so having it late in the search path
seems reasonable.
- the effect of CONFIG+=depend_includepath is now fully consistent with
the actual include path.
Change-Id: I5f7570183351ade29342ea74fef706a0738842bf
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On Windows, the application manifest file can be linked with the
executable, to specify for example the requested privileges of the
application. On MSVC nmake, the manifest is already handled in
NmakeMakefileGenerator::writeBuildRulesPart, but it is not compatible
with MinGW. On MinGW, this manifest file has to be referenced in the
Rc File. This patch simply handles the existing variable
"QMAKE_MANIFEST" which defines the appropriate line RT_MANIFEST in
the RC file.
Task-number: QTBUG-42454
Change-Id: I921606e002ffe3801c537f30ac2365891f97d5c9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
At the very least, include the files named in the sources, like
HEADERS. It was quite surprising to send a tarball that included the
.pro file and the .cpp sources, but none of the headers.
On the other hand, the .qmake.cache file need need not be sent either,
despite being include()d in qmake's processing.
Change-Id: I8f48ca3e8040f954f321f4643b01c0f36aafe2d7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This variable works like CLEAN_DEPS, but applies to the distclean target.
Change-Id: Ia30e8932b9acd6529298728dd5d0e038b0208d66
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the diff -w for this commit is empty.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the problem is that there is no sed command on windows ... so build it
into qmake and invoke that from the generated makefiles. cmake does the
same, after all. ^^
Task-number: QTBUG-33794
Change-Id: Ib7077e18acbc5edd79f714c5779a5ed31ea6c093
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Shared between UNIX and Win generators, and allows prfs after
default_post to rely on sane TARGET and DESTDIR values.
This allows us to clean up the DESTDIR logic in testcase.prf,
which was completely busted. Doing the two in separate commits
is unfortunately not possible as the old testcase.prf logic
was so broken it would barf if only looked at.
Change-Id: Ibf21216195c760ee46ae679c162b207b77a9d813
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qmake has the rather bizarre logic that QMAKE_LIBS* is escaped rather
early (instead of right before being written out the the Makefile).
consequently, we need to explicitly escape the paths from the prl files
as well.
Task-number: QTBUG-32326
Change-Id: Ieaf81113d3ca3cf5d8a1ef87c83c5721d6b473ee
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
escape backslashes before the quotes, as otherwise we'd escape the
backslashes we just used to escape the quotes.
Change-Id: I88e12c0c2cfc53e0ab8dce9807b06dfce6aa6e78
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
makes for less visual noise and a tiny bit more efficient code.
Change-Id: I587707fa4e2dc9bead9435bf5caf3a98ab680725
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The undocumented feature of linking the library with the highest
version number is more confusing than helpful.
We're changing the default from on to off now.
Users who still need this feature can turn it on with:
CONFIG += link_highest_lib_version
Task-number: QTBUG-15596
Change-Id: Ic998c1685003caa6f57e27dccf83c8b4a2a09553
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Curiously, qmake could fix .prl and .pc files for unix, but only .pc
files for MinGW. qt_module.prf seems to have known this.
Task-number: QTBUG-28902
Change-Id: Ice9983a69813690c0d4b96ca11589440182569a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Metafiles such as .prl and .pc files contain paths that have to be
adjusted during installation. The same code is used for unix and
windows so move it into the base class.
Change-Id: I82db89ec83820a4fa0214ba15e7cd63438f6dc91
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
A new qmake's variable RC_ICONS is introduced to specify the icons.
The first one will be used as the application's icon.
Change-Id: I4218db795837d470087dff8526eb0e4cb81ce5ed
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
In RC_INCLUDEPATH one can add include paths for the Windows resource
compiler.
Task-number: QTBUG-13776
Change-Id: If1d9ed44097adb7789df03e4ccd4e3b7df9e8d08
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
ProductVersion is set to the same value as FileVersion.
Task-number: QTBUG-27428
Change-Id: Ia01e14112d3a0e74b9fbe5fc8d9c4f9ae690db34
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Rename LINK to LINKER. The MSVC linker uses the environment
variable LINK to pass additional command line arguments.
We must not hide this variable.
Task-number: QTBUG-28332
Change-Id: Id78476d1cf4a73175b9f47292c67f38a43ae5ba4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The LIBS statement generated into Makefiles contained duplicate
libraries when application was linking static libraries.
Fixed by adapting the logic from unixmake.cpp's version of
processPrlFiles() to remove duplicates.
Change-Id: I12e152900233d0376b7d7ac6cd18a92850a6d640
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qmake automatically appends the library's major version number to the
DLL file name on Windows, as DLL naming doesn't include the version
number on a suffix like on Unix systems.
This flag makes it so qmake skips adding. This will allow us to insert
Qt's major version number at a different position.
Change-Id: I25d471038841fb0c5a34ef6b3bd6266aa33cebd1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
This is an automated change performing the following replacements:
join\("(.)"\) -> join('\1')
join\(QLatin1String\("(.)"\)\) -> join(QLatin1Char('\1'))
join\(QStringLiteral\("(.)"\)\) -> join(QLatin1Char('\1'))
Change-Id: I9c9964703dedfdab6e7bfac80be22bd5570e2e49
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is preparation for adapting to a new evaluator.
Change-Id: I6fc59f5525735754a00afa6629fbfe257e84db97
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
don't read the spec from scratch for every library just to get
QMAKE_LFLAGS_RPATH. we can perfectly use our current project for that
purpose.
Change-Id: I4e408b3fd5de81652181df032aa53cd8f2f8f806
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it was unused for a decade. and broken, of course.
Change-Id: I9713d595d95c5b074ef96dfe9b1c314b9198bd7e
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
there is no reason why private libs should not have prls resolved.
the two variables are resolved independently, so it's possible that
(even more) libraries will appear duplicated on the linker command line,
but that seems easiest for the time being.
Change-Id: I9070ba53808a0661fa72949db8111106b7aca487
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it's more elegant, and more similar code is better.
Change-Id: I2b8b036cb70a932fd171e23cf7d3389188401924
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it wouldn't actually *do* anything, as l is not a reference. i cannot
figure out the original intention, so let's just drop it.
Change-Id: Ic0a3457a1872cde827259ee5530959120456e934
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
dealing with the directories separately doesn't buy us anything. it's
easier to mix them into the libs, as that contains some paths, too, both
in projects and in prl files.
this brings the windows generators in line with the unix ones.
Change-Id: I1f58f7edd8e21d28bfabf04384bac2e315aaf446
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
unlike for the unix linker, this does not matter for the windows linker,
but keeping it consistent has advantages.
Change-Id: Ib9b9efa18c31d87c026d3cac5a8737f4612ad1c0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
this way QMAKE_LIBS{,_PRIVATE} can be treated the same as in all other
generators, which allows us to:
- make the windows generators' findLibraries() be more like the unix
version
- dispose of QMAKE_INTERNAL_PRL_LIBS handling while reading prl files
(because the output always goes to QMAKE_LIBS)
- as a side effect, QMAKE_LIBS_PRIVATE are not subjected to prl file
resolution any more, which is again consistent with unix - the
correctness of that needs to be assessed separately.
Change-Id: Ie9bc04d117eff6a7cde846677f98acf3c64aa6ee
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
the libinfix provides a way cleaner solution to that. i don't expect it
to be still actually used anyway.
Change-Id: I051522ec3abb3d92c529b5462b8514a706aa2ba1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@digia.com>
it's a tad insane to expect the user to do that
Change-Id: I75c68f2a28656c9ba2e3fabcc79718b899b29ce7
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Since Windows Vista the resource language must be included to
make the version information visible in Windows Explorer.
Two new variables have been introduced:
RC_LANG (default: 1033) - resource language
RC_CODEPAGE (default: 1200) - resource codepage
Task-number: QTBUG-23218
Change-Id: I29e102d19501e3b7a43d5096fc4806bc38a4d846
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
This implements replacements for win32 makefile generators similar
to the replacement functionality in unix makefile generators.
To enable Makefile code generation for replacements in win32 makefile
generators, you must set QMAKE_STREAM_EDITOR to e.g. sed.
When building for win32, sed is normally only available in the
mingw/msys build environment and when cross compiling on unix.
In these cases QMAKE_STREAM_EDITOR is set to sed in qmake.conf.
For other win32 build environments QMAKE_STREAM_EDITOR is not set
in qmake.conf and the replacements Makefile code is not generated.
Change-Id: Ie5de5d517eafaeaa2544f1e972aec3fe11d0a6f1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
