A bug in the Windows C Runtime causes text mode pipes to drop newlines
sometimes. This bug was hidden because of another bug in rcc which
caused newlines to be redundantly duplicated. When the latter bug was
fixed (commit 53d5811b) the former bug was exposed, causing invalid
vcxproj files to be generated. The Windows bug is described here:
https://connect.microsoft.com/VisualStudio/feedback/details/1902345
The workaround is to avoid text mode, and do the conversion of "\r\n"
to "\n" ourselves (which we were already doing anyway).
Change-Id: I792599a4cd7822f109fa921f02207fb1b144b1d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This resolves an issue where qmake would generate a Makefile with an
install command immediately followed by a test command, with no
intermediary newline and tab to separate them.
Task-number: QTBUG-54035
Change-Id: I7f9226f25e92b49ce689d252e9c4a58b877f2972
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The two PDB files that the MSVC compiler and linker create are supposed
to be handled differently and should not share the same file path.
Using the same file path for both can result in corrupted PDB files and
longer build times.
Use $${TARGET}.vc.pdb in the OBJECTS_DIR for the compiler and
$${TARGET}.pdb (the default) for the linker.
Task-number: QTBUG-53895
Change-Id: I31f06d4a674a3aa2afe5b30499bae820e5caf2c4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
While previous SDKs used the form "CE_SDK (CE_ARCH)" in their
configuration/platform names, this is not true fo the Toradex SDK.
Inside Visual Studio the platform is only called "Toradex_CE800"
instead of "Toradex_CE800 (ARMV7)".
In order not to break other SDKs CE_PLATFORMNAME is introduced and
used in the wince80colibri-armv7-msvc2012 mkspec. If the variable
is set qmake uses it as the platform name in its vcproj generator.
Change-Id: Icb501bf6446a9f617745a0d2c7a80b240680b043
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
- QMAKE_FILE_IN_EXT as an alias for QMAKE_FILE_EXT, for consistency with
QMAKE_FILE_IN_BASE
- QMAKE_FILE_IN_NAME to make pairing _EXT/_BASE to get a full name
unnecessary (finally ...), and make use of it
- QMAKE_FILE_OUT_PATH, because i'll need it
Change-Id: I3d91ddb84f9cce52a665d562da11d165c92550c8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it's beyond me why they shouldn't be.
Change-Id: I2493469636e4f196bfeb2eb00a691aeae0f1881d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
CID 155005: Possible illegal access in string. Some loops were
reading the buffer without checking the bounds.
Change-Id: I910671a6d56808138ec2bb5d96bd7edf78b20f73
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
CID 21629: The QMakeProject::read result was ignored.
MetaMakefileGenerator::createMakefileGenerator will be called if the
project was read.
Change-Id: I9187c82efd1abedcaa8e394f1fdb0b7f35a2b1d7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Xcode does not recognize "<Group>" with a capital G, only "<group>" with
a lowercase g. As a result, paths of files within these groups are
calculated incorrectly. For example, dragging any external file into the
Xcode project would result in its leading slash being removed (while
still treated as an absolute path - broken reference). Furthermore, the
dropdown in Xcode displayed the Group location as an invalid string
instead of the correct "Relative to Group". This patch restores correct
behavior.
This fixes a regression introduced in
f09ec09c208c75a16abe05b6bb505a1fc58775a6.
Task-number: QTBUG-52701
Change-Id: I9af5360049a79e7958301e4090a9a542bab0af8c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
This fix repairs the mechanism to deploy Qt dlls as well as C++ runtime
to a wince target in Visual Studio.
Do this by adding a deploy section in the Visual Studio solution and
adding the C++ runtime from the mkspec to the files deployed to the target.
Deploy target path is set to what the wizard of Visual Studio defaults to.
Before, the c++ runtime was only deployed for executables which were built
as part of Qt.
Task-number: QTBUG-50924
Change-Id: I478010dc16e35c68578281895aa3ae14b5c96bb4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
we can rely on the super class to get it right.
as a "side effect", we won't try to install .pdb files for aux projects
anymore - the duplicated conditional was incomplete.
Change-Id: I9b66f32ab50ed2a1d4e6e03a9d205686a4b4a981
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Found by UBSan:
qmake/library/qmakeparser.cpp:278:33: runtime error: null pointer passed as argument 2, which is declared to never be null
Guard the call.
Change-Id: I99341ab439a511f366dae9344ddcc8727c33b9b6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
evidently, nothing and nobody sets this option, as it's been completely
broken since 6234dec41f (qt 5.5) and apparently nobody noticed.
Change-Id: I5a82ebd963a292af4689397875dde096f63d751a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
QFileInfo::exists(f) is somewhat faster than the version which creates an temporary object.
Change-Id: I5f931a86d9dfad57d99efe04ca115422de43def9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Having a precompiled header file without file extension (or without
common file extension) led to an incorrectly generated Visual
Studio project file. The custom build step for automatically
generating the corresponding source file was missing.
Remove the file extension check that apparently was yet another
feeble attempt of runtime optimization.
Task-number: QTBUG-50442
Change-Id: I0552f94be12cbb70e2f32c242c7364699979bd81
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Previously the hardware and camera button handler were guarded inside a
Q_OS_WINPHONE which does not apply to Windows 10.
Instead use WINAPI_PARTITION_FAMILY like on other places, this covers
Windows Phone 8.1 as well as Windows 10.
To find windows.phone.ui.input.h at build time the Mobile Extension
directory needs to be added to the include paths inside qmake. On
runtime we need to check whether we have hardware buttons or not. In
case they exist, register the handlers, otherwise skip registration.
Skipping also helps to keep WACK succeeding.
Task-number: QTBUG-50427
Change-Id: Ibeae15dbde12553cebd2b73b1a40b754c014f426
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
the primary purpose is making env var prepend mode work for unset
variables on windows. this is achieved by using a conditional and delayed
variable expansion. however, the latter is disabled by default and can
be locally enabled only in batch files. therefore, write wrapper scripts
and substitute them for the actual commands. we do this also on unix,
both for consistency and simply because the commands look much less
confusing.
this change is slightly backwards-incompatible, as invoking
qtAddToolEnv() multiple times on the same command will now make a total
mess. also, invoking it on a command that contains 'make' macro
expansions isn't a good idea, so testcase.prf needed an adjustment. the
function is an undocumented internal, so Nobody Should Care (TM).
this also reverts 80ebedecf9, as it's obsolete now.
Change-Id: I8394b77868b495abcf27b688996ca74c40b80994
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
In 50bf54c invoking windeployqt was only required in release mode as
MDILXapCompile was not invoked for debug builds with Visual Studio 2013.
However, Visual Studio 2015 invokes MDILXapCompile for debug and
release. Hence we have to use this workaround unconditionally.
Also we cannot limit this to msvc2015 host specs only, as older projects
still might be loaded with Visual Studio 2015 causing the build to
break.
Task-number: QTBUG-49815
Change-Id: Ia120a392967319b945a9746ad489f2db0eed7156
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
while we evaluate the features themselves in precise mode (which is the
reason why they can error out), we do not want them to terminate
cumulative project evaluation.
Change-Id: I70f3e1bcb2ca04a70c74ff484749ca92c1cf6372
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
(cherry picked from qttools/90ee4094161b427c32581bca2f5286edb4fffdb1)
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
After 90e7cc172a, QStringList no longer
includes QDataStream.
This also reverts commit c1be0fbe7d, which
did the same in a worse way.
Change-Id: Ib10622b0da3b3450d29fc65dc5356fde75444a8f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
(cherry picked from qttools/376501ae5a86859821c0e89b2e8fbc9906d11e07)
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
As for the #include-parser, the moc-detector's minimal C preprocessor
could be confused by a raw string into ignoring large chunks of code.
Change-Id: Id688e9a1f04628ce75a51a7d15269078c734288e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
If a / wasn't part of a comment-start, it and the character after it
were none the less stepped over. If the character after started an
enclosure, this would duly be missed, leading to mis-parsing of the
subsequent text. As for similar bug recently fixed in findDeps().
Change-Id: Ie5329ec633c23a554b42a6351723c980e27fb9a9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The C preprocessor allows backslash-newline anywhere and allows
comments anywhere it allows space. Testing wilfully perverse
applications of that revealed qmake's parsing of #include directives
wasn't very robust. So rework to actually follow the rules and add
those tests.
Change-Id: If5cc7bfb65f9994e9ab9ed216dd1ee7285c63934
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The parser in QMakeSourceFileInfo::findDeps() would step over the
closing quote of a string, only to have a for loop then step over the
character just after that closing quote, which was thus never studied;
this could lead to problems in various ways. Fixed that and expanded
findDeps() test to catch regressions.
Task-number: QTBUG-17533
Change-Id: I7dec5222e38fa188495b39376ffee70bc7bbc87f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This information is outdated.
Change-Id: Ic2e10f7c858eed6f1b7c550995cb29004b4bd280
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Can't sensibly test unless the compiler does support raw strings,
since any test that would catch qmake's (prior) inability to parse raw
strings would necessarily confuse the C++ compiler in the same way.
This even applies (in test app code) to any #if-ery around the raw
string, since tokenization happens before preprocessor directives are
resolved. So the #if-ery on Q_COMPILER_RAW_STRINGS has to be in
tst_qmake.cpp, not the test app it builds.
Change-Id: I4a461f515adff288b54fb273fd9996f9b906d11c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The Visual Studio registry keys are stored in the 32 bit view.
Extend qt_readRegistryKey with an option that enables the caller to
choose the 32 bit or 64 bit registry view.
We now read the Visual Studio registry keys from the 32 bit registry
view even in a 64 bit build.
Adding the next Visual Studio version will become a bit easier.
Change-Id: I7300b992be6058f30a422e3f1fe0bafade6eea54
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
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>
