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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Commit 4bb004de94 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>
... 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
"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>
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>
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>
the code had a dead variable assignment and no side effects.
Change-Id: I9add8f1776f23a29c103b46dc725b9f386a4495a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
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>
