When compiling on Windows to for example Android, we may be using the unix
generator, but the make command may be mingw32-make.
Task-number: QTBUG-53038
Change-Id: If8d1e1bea733cf1b4ed837c423a34ecfb3cafd1f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
... to avoid that inherited MAKEFLAGS turn out to be incompatible with
the make we choose.
Task-number: QTBUG-39527
Change-Id: I47d4cec58b0643cc5d97868e70b24f7f37e964bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Compared to other platforms there is no concept of a console
application in WinRT. Hence all applications need to be UI
applications and use winmain.
Furthermore winmain takes care of launch arguments to be
properly converted to arguments passed to user's main().
There is a chicken and egg problem with config.tests as
compilation needs to have an existing entry point which is not
available at configure time.
Hence hardcode the entry point to main for configuring to WinRT.
Those tests are pure compile tests, so the logic of the test
does not change.
Change-Id: I4d3186691a8440845c24b2529cc9646e86dfd8da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qmake expects the generator to be the same for each node in the tree
of subdirs, including the leaf projects, which caused failures when
qmake tried to recurse out to the leaf projects and run 'make', when
the leaf project was an Xcode project.
We now wrap the Xcode project in a meta-makefile that just
calls out to xcodebuild to do the actual work. This allows us
to get rid of the hacky generator detection, and use the macx-xcode
mkspec instead of setting the generator, which is much cleaner.
Change-Id: I2fed6a4dd6343b6a320eb459ecae824553bff459
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
configure.prf checks if MAKEFILE_GENERATOR is set
to something it can work with. ios/default_pre.prf
unsets MAKEFILE_GENERATOR.
This breaks QtMultimedia at least. Add special case
for iOS to configure.prf and set QMAKE_MAKE to "make".
Change-Id: Ie8feaeefe4a932d735a0cd4c09e869ca1341aae5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Cross bulding on unix for mingw exploits the fact that makefiles
generated for mingw work with plain make. There is no mingw32-make, so
this is the only option.
Arguably, plain make could also be used in an MSYS environment,
perhaps detected by MINGW_IN_SHELL, but there might be good reasons I
don't know about not to do this.
Change-Id: I694c74046a307c2887af1c30cca36f95e242adc1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the system path separator and shell are bound to the host system
(system() will use cmd even on mingw with sh.exe in path).
the makefiles otoh may depend on what the qmakespec defines.
consequently, add $$system_path() and $$system_quote() (for use with
system() & $$system()). $$native_path() is renamed to $$shell_path() and
should be used with $$shell_quote() to produce command lines in
makefiles.
$$QMAKE_DIR_SEP needs to be applied to Option::dir_sep right after
parsing the spec, so it is available to $$shell_{path,quote}().
Change-Id: If3db4849e7f96068cf03a32348a24f3a72d6292c
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
this fully replaces qtmodule-configtests.
it is way shorter and it actually integrates reasonably with qmake.
Change-Id: I819cc6807ad3661c419b54fa253894936dd88a64
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
