AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e8cf0bf5f8
qt5base-lts/mkspecs/common/msvc-desktop.conf

107 lines
4.1 KiB
Plaintext
Raw Normal View History

Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
#
# qmake configuration for Microsoft Visual Studio C/C++ Compiler
Merge all "win32-msvc*" mkspecs into one Since we can tell the MSVC version from the compiler now, each of the qmake.conf files is now the same, so let's just have "win32-msvc" and be future-proof. Likewise for win32-clang-msvc. qplatformdefs.h was already common. Since we can't obtain the MSVC version from the unified mkspec name any more, I dropped the warning level during the qmake bootstrap to reduce the number of warnings that need to be disabled from compiler version to version. There is no point in keeping the old mkspecs, but configure will re-map the -platform argument to the unified spec as necessary, to keep existing configure command lines working. [ChangeLog][Visual Studio] Qt now has a common mkspec for all Visual Studio versions, called "win32-msvc". The old names which contained the version number are now gone (but qmake scopes based on the old names continue to work). The version of the compiler can be obtained from the MSC_VER and MSVC_VER variables (for example, for Visual Studio 2015, those contain the values 1900 and 14.0, respectively). Those variables are also available with the Intel compiler (win32-icc) and with Clang (win32-clang-msvc). Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Change-Id: Ib57b52598e2f452985e9fffd14587c0a77a5c09c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2016-06-16 06:21:03 +00:00
# This mkspec is used by the win32-msvc and win32-clang-msvc specs
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
#
#
# Baseline: Visual Studio 2005 (8.0), VC++ 14.0
Remove hard-coded MS compiler versions from the mkspecs We're asking the compiler anyway, so we can fully use this information just as well. Note that this actually happens after the spec itself has been processed, so it was necessary to delay the version-specific flag handling as well. Change-Id: Ib57b52598e2f452985e9fffd14587b581d946022 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2016-11-16 13:18:42 +00:00
# Version-specific settings go in msvc-version.conf (loaded by default_pre)
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
#
MAKEFILE_GENERATOR = MSVC.NET
QMAKE_PLATFORM = win32
QMAKE_COMPILER = msvc
CONFIG += incremental flat precompile_header autogen_precompile_source debug_and_release debug_and_release_target embed_manifest_dll embed_manifest_exe
DEFINES += UNICODE WIN32
determine compiler version at build time, not in configure this makes it consistent with the determination of the default include/library paths. this makes sense, as it's possible to switch the sdk/toolchain after building qt (within reason). a side effect of this change is that for compilers which emulate other compilers, both the real and the emulated version are now made available. Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c Started-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2016-12-15 15:20:27 +00:00
QMAKE_COMPILER_DEFINES += _WIN32
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
contains(QMAKE_TARGET.arch, x86_64) {
DEFINES += WIN64
QMAKE_COMPILER_DEFINES += _WIN64
}
QMAKE_CC = cl
QMAKE_LEX = flex
QMAKE_LEXFLAGS =
Makes sure that yacc works with the MSYS bison on Windows. Most people's yacc are actually a symlink to bison. On Windows, where symlinks don't usually exist, we can use bison -y. This was tested with MSYS Bison. Change-Id: I913745d48af30f9ef7b846b6438500261dd6022d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-06-24 20:18:48 +00:00
QMAKE_YACC = bison -y
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_YACCFLAGS = -d
MSVC: Remove use of -Zm argument We've been setting the -Zm argument since the dawn of times (even before the first git commit). Anyhow, MSDN from VS2008 onwards indicates that this is not needed: "In earlier versions of Visual C++, the compiler used several discrete heaps, and each had a finite limit. Currently, the compiler dynamically grows the heaps as necessary up to a total heap size limit, and requires a fixed-size buffer only to construct precompiled headers. Consequently, the /Zm compiler option is rarely necessary." [ChangeLog][Compiler Specific Changes] Visual Studio: -Zm200 (an option to specify the precompiled header memory allocation limit) is not added anymore by qmake to the compiler calls. If you encounter an C1076 compiler error you might need to re-add it in your .pro file. Change-Id: Ia4bec7eba09d893a7d81886a1814602b9ce7563c Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
2015-01-12 15:05:00 +00:00
QMAKE_CFLAGS = -nologo -Zc:wchar_t
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_CFLAGS_WARN_ON = -W3
QMAKE_CFLAGS_WARN_OFF = -W0
QMAKE_CFLAGS_RELEASE = -O2 -MD
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MD -Zi
QMAKE_CFLAGS_DEBUG = -Zi -MDd
QMAKE_CFLAGS_YACC =
QMAKE_CFLAGS_LTCG = -GL
Silence cl.exe warning about -arch:SSE2 being unknown in 64-bit builds That implies we need to differentiate between a variable set but empty and an empty variable. GCC, Clang and the Intel compiler accept -msse2 on 64-bit builds without warning (they also accept -mno-sse2), but the Microsoft compiler does not have that option. Change-Id: I54233388ba10994996ae3e749fd829085e8fd7b7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-11-16 22:56:07 +00:00
contains(QMAKE_TARGET.arch, x86_64) {
# SSE2 is mandatory on 64-bit mode, so skip the option. It triggers:
# cl : Command line warning D9002 : ignoring unknown option '-arch:SSE2'
QMAKE_CFLAGS_SSE2 =
} else {
QMAKE_CFLAGS_SSE2 = -arch:SSE2
}
QMAKE_CFLAGS_SSE3 = $$QMAKE_CFLAGS_SSE2
QMAKE_CFLAGS_SSSE3 = $$QMAKE_CFLAGS_SSE2
QMAKE_CFLAGS_SSE4_1 = $$QMAKE_CFLAGS_SSE2
QMAKE_CFLAGS_SSE4_2 = $$QMAKE_CFLAGS_SSE2
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_CXX = $$QMAKE_CC
QMAKE_CXXFLAGS = $$QMAKE_CFLAGS
MSVC: Disable compiler warning 4996 for debug builds Move compiler warning 4996 from level 3 to 4. This is needed to avoid warnings about the use of C++ standard library functions like std::copy, which is used e.g. in qvector.h (since c6752c5aa19): 'std::copy': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' Because the warning has to be disabled before any standard C++ header is included one cannot just fix this locally in qvector.h. Change-Id: I929f1535656bca9f5beb7fd0d557178370c232c6 Reviewed-by: Marc Mutz <marc.mutz@kdab.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
2015-01-07 12:21:03 +00:00
QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CFLAGS_WARN_ON -w34100 -w34189 -w44996
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_CXXFLAGS_WARN_OFF = $$QMAKE_CFLAGS_WARN_OFF
QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_CXXFLAGS_DEBUG = $$QMAKE_CFLAGS_DEBUG
QMAKE_CXXFLAGS_YACC = $$QMAKE_CFLAGS_YACC
QMAKE_CXXFLAGS_LTCG = $$QMAKE_CFLAGS_LTCG
QMAKE_CXXFLAGS_STL_ON = -EHsc
QMAKE_CXXFLAGS_STL_OFF =
QMAKE_CXXFLAGS_RTTI_ON = -GR
QMAKE_CXXFLAGS_RTTI_OFF =
QMAKE_CXXFLAGS_EXCEPTIONS_ON = -EHsc
fix C4275 warnings for MSVC 2010 build This issue had been fixed by SHA: a12a2fdf684a6fc19aefc14f32842deab0270e86 but re-introduced by SHA: c23d1c76953704ecb52c833d7ef1de2e2f89b1e6 again. Task-number: QTBUG-45085 Change-Id: If98ee108335d80035179a83b1b28f384395d8373 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
2015-03-26 03:48:58 +00:00
QMAKE_CXXFLAGS_EXCEPTIONS_OFF =
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_INCDIR =
QMAKE_RUN_CC = $(CC) -c $(CFLAGS) $(INCPATH) -Fo$obj $src
QMAKE_RUN_CC_IMP = $(CC) -c $(CFLAGS) $(INCPATH) -Fo$@ $<
QMAKE_RUN_CC_IMP_BATCH = $(CC) -c $(CFLAGS) $(INCPATH) -Fo$@ @<<
QMAKE_RUN_CXX = $(CXX) -c $(CXXFLAGS) $(INCPATH) -Fo$obj $src
QMAKE_RUN_CXX_IMP = $(CXX) -c $(CXXFLAGS) $(INCPATH) -Fo$@ $<
QMAKE_RUN_CXX_IMP_BATCH = $(CXX) -c $(CXXFLAGS) $(INCPATH) -Fo$@ @<<
QMAKE_LINK = link
QMAKE_LFLAGS = /NOLOGO /DYNAMICBASE /NXCOMPAT
QMAKE_LFLAGS_RELEASE = /INCREMENTAL:NO
QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO = /DEBUG /OPT:REF /INCREMENTAL:NO
QMAKE_LFLAGS_DEBUG = /DEBUG
QMAKE_LFLAGS_CONSOLE = /SUBSYSTEM:CONSOLE
QMAKE_LFLAGS_WINDOWS = /SUBSYSTEM:WINDOWS
QMAKE_LFLAGS_EXE = \"/MANIFESTDEPENDENCY:type=\'win32\' name=\'Microsoft.Windows.Common-Controls\' version=\'6.0.0.0\' publicKeyToken=\'6595b64144ccf1df\' language=\'*\' processorArchitecture=\'*\'\"
QMAKE_LFLAGS_DLL = /DLL
QMAKE_LFLAGS_LTCG = /LTCG
unify handling of library prefixes and extensions 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>
2015-09-29 10:44:30 +00:00
QMAKE_PREFIX_SHLIB =
QMAKE_EXTENSION_SHLIB = dll
QMAKE_PREFIX_STATICLIB =
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_EXTENSION_STATICLIB = lib
QMAKE_LIBS_CORE = kernel32.lib user32.lib shell32.lib uuid.lib ole32.lib advapi32.lib ws2_32.lib
QMAKE_LIBS_GUI = gdi32.lib comdlg32.lib oleaut32.lib imm32.lib winmm.lib ws2_32.lib ole32.lib user32.lib advapi32.lib
QMAKE_LIBS_NETWORK = ws2_32.lib
QMAKE_LIBS_OPENGL = glu32.lib opengl32.lib gdi32.lib user32.lib
Merge ANGLE's libEGL and libGLESv2 into QtANGLE This is needed in order to be able to specify a custom location of the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs by just having the absolute path to QtANGLE.dll as the argument to LoadLibrary(). Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard linked against libGLESv2. If we wanted to load libEGL from a custom location, we couldn't load libEGL by calling LoadLibrary with the absolute path to libEGL, because libEGL had problems finding libGLESv2. One solution to that could have been to call SetDllDirectory() with the path to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL directory would point to both ANGLE libs, this would ensure that the libGLESv2 was also found. Unfortunately, this approach is not thread safe (SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same process). Therefore, we chose to merge the two libraries into one to circumvent the whole problem. At the same time, this patch also enables loading of two different ANGLE libraries into the same process at once without renaming them: This was not possible before because libEGL hard linked to libGLESv2.dll. When libGLESv2.dll was already loaded, the second instance of libEGL would simply link against the already loaded version of libGLESv2.dll. This behavior is documented in the LoadLibraryEx documentation on MSDN: "If the string specifies a module name without a path and more than one loaded module has the same base name and extension, the function returns a handle to the module that was loaded first." Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-10-25 14:56:02 +00:00
QMAKE_LIBS_OPENGL_ES2 = gdi32.lib user32.lib
QMAKE_LIBS_OPENGL_ES2_DEBUG = gdi32.lib user32.lib
Create a common qmake configuration for all MSVC versions Most files are exactly the same, so it's silly to duplicate this all over. The differences could have been kept in each of the qmake.conf files, but I preferred to centralize because they apply to each newer version and, soon enough, version-specific configuration would grow again. Change-Id: I5c5ed58055c954acf4851d87c70cc5af49c98738 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2014-11-20 01:43:21 +00:00
QMAKE_LIBS_COMPAT = advapi32.lib shell32.lib comdlg32.lib user32.lib gdi32.lib ws2_32.lib
QMAKE_LIBS_QT_ENTRY = -lqtmain
QMAKE_IDL = midl
QMAKE_LIB = lib /NOLOGO
QMAKE_RC = rc
VCPROJ_EXTENSION = .vcproj
VCSOLUTION_EXTENSION = .sln
VCPROJ_KEYWORD = Qt4VSv1.0
Merge ANGLE's libEGL and libGLESv2 into QtANGLE This is needed in order to be able to specify a custom location of the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs by just having the absolute path to QtANGLE.dll as the argument to LoadLibrary(). Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard linked against libGLESv2. If we wanted to load libEGL from a custom location, we couldn't load libEGL by calling LoadLibrary with the absolute path to libEGL, because libEGL had problems finding libGLESv2. One solution to that could have been to call SetDllDirectory() with the path to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL directory would point to both ANGLE libs, this would ensure that the libGLESv2 was also found. Unfortunately, this approach is not thread safe (SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same process). Therefore, we chose to merge the two libraries into one to circumvent the whole problem. At the same time, this patch also enables loading of two different ANGLE libraries into the same process at once without renaming them: This was not possible before because libEGL hard linked to libGLESv2.dll. When libGLESv2.dll was already loaded, the second instance of libEGL would simply link against the already loaded version of libGLESv2.dll. This behavior is documented in the LoadLibraryEx documentation on MSDN: "If the string specifies a module name without a path and more than one loaded module has the same base name and extension, the function returns a handle to the module that was loaded first." Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
2016-10-25 14:56:02 +00:00
include(windows-gles.conf)
Reference in New Issue Copy Permalink