qt5base-lts/mkspecs/common/msvc-desktop.conf

110 lines
4.2 KiB
Plaintext
Raw Normal View History

#
# qmake configuration for Microsoft Visual Studio C/C++ Compiler
# This mkspec is used by the win32-msvc and win32-clang-msvc specs
#
#
# Baseline: Visual Studio 2005 (8.0), VC++ 14.0
# Version-specific settings go in msvc-version.conf (loaded by default_pre)
#
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
QMAKE_COMPILER_DEFINES += _WIN32
contains(QMAKE_TARGET.arch, x86_64) {
DEFINES += WIN64
QMAKE_COMPILER_DEFINES += _WIN64
}
QMAKE_CFLAGS_OPTIMIZE = -O2
QMAKE_CFLAGS_OPTIMIZE_SIZE = -O1
QMAKE_CC = cl
QMAKE_LEX = flex
QMAKE_LEXFLAGS =
QMAKE_YACC = bison -y
QMAKE_YACCFLAGS = -d
QMAKE_CFLAGS = -nologo -Zc:wchar_t
QMAKE_CFLAGS_WARN_ON = -W3
QMAKE_CFLAGS_WARN_OFF = -W0
QMAKE_CFLAGS_RELEASE = $$QMAKE_CFLAGS_OPTIMIZE -MD
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_OPTIMIZE -MD -Zi
QMAKE_CFLAGS_DEBUG = -Zi -MDd
QMAKE_CFLAGS_YACC =
QMAKE_CFLAGS_LTCG = -GL
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
QMAKE_CXX = $$QMAKE_CC
QMAKE_CXXFLAGS = $$QMAKE_CFLAGS
QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CFLAGS_WARN_ON -w34100 -w34189 -w44996
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
QMAKE_CXXFLAGS_EXCEPTIONS_OFF =
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
QMAKE_PREFIX_SHLIB =
QMAKE_EXTENSION_SHLIB = dll
QMAKE_PREFIX_STATICLIB =
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
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)