2011-04-27 10:05:43 +00:00
|
|
|
#
|
|
|
|
# qmake configuration for win32-icc
|
|
|
|
#
|
|
|
|
# Written for Intel C++
|
|
|
|
#
|
|
|
|
|
2016-06-16 19:22:55 +00:00
|
|
|
# Use the Visual Studio configuration
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2016-06-16 19:22:55 +00:00
|
|
|
include(../common/msvc-desktop.conf)
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2016-06-16 19:22:55 +00:00
|
|
|
# Now override with the Intel compiler settings
|
|
|
|
|
|
|
|
QMAKE_COMPILER += intel_icl # icl pretends to be msvc
|
2012-09-13 20:17:33 +00:00
|
|
|
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_CC = icl
|
2016-12-05 05:29:06 +00:00
|
|
|
QMAKE_CFLAGS = -nologo -Zm200 /Qprec /Qwd1744,1738,809,3373
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_CFLAGS_WARN_ON = -W3 /Qwd673
|
|
|
|
QMAKE_CFLAGS_WARN_OFF = -W0 /Qwd673
|
2014-06-24 18:22:40 +00:00
|
|
|
QMAKE_CFLAGS_DEBUG = -Zi -MDd -Od
|
2014-06-26 21:56:06 +00:00
|
|
|
QMAKE_CFLAGS_LTCG = -Qipo
|
2015-09-02 18:48:51 +00:00
|
|
|
QMAKE_CFLAGS_DISABLE_LTCG = -Qno-ipo
|
2014-06-24 18:22:40 +00:00
|
|
|
QMAKE_CFLAGS_SSE2 = -QxSSE2
|
|
|
|
QMAKE_CFLAGS_SSE3 = -QxSSE3
|
|
|
|
QMAKE_CFLAGS_SSSE3 = -QxSSSE3
|
|
|
|
QMAKE_CFLAGS_SSE4_1 = -QxSSE4.1
|
|
|
|
QMAKE_CFLAGS_SSE4_2 = -QxSSE4.2
|
|
|
|
QMAKE_CFLAGS_AVX = -QxAVX
|
|
|
|
QMAKE_CFLAGS_AVX2 = -QxCORE-AVX2
|
2015-07-17 21:46:05 +00:00
|
|
|
QMAKE_CFLAGS_AVX512F += -QxCOMMON-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512CD += -QxCOMMON-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512ER += -QxMIC-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512PF += -QxMIC-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512DQ += -QxCORE-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512BW += -QxCORE-AVX512
|
|
|
|
QMAKE_CFLAGS_AVX512VL += -QxCORE-AVX512
|
2017-04-03 23:05:18 +00:00
|
|
|
QMAKE_CFLAGS_F16C = $$QMAKE_CFLAGS_AVX2
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_CXX = $$QMAKE_CC
|
|
|
|
QMAKE_CXXFLAGS = $$QMAKE_CFLAGS /Zc:forScope
|
|
|
|
QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CFLAGS_WARN_ON
|
|
|
|
QMAKE_CXXFLAGS_WARN_OFF = $$QMAKE_CFLAGS_WARN_OFF
|
2014-06-24 01:43:06 +00:00
|
|
|
QMAKE_CXXFLAGS_CXX11 = -Qstd=c++11
|
2015-07-09 00:21:30 +00:00
|
|
|
# ICC supports the following but Qt won't compile
|
|
|
|
#QMAKE_CXXFLAGS_CXX14 = -Qstd=c++14
|
|
|
|
#QMAKE_CXXFLAGS_CXX1Z = -Qstd=c++1z
|
2014-06-26 21:56:06 +00:00
|
|
|
QMAKE_CXXFLAGS_LTCG = $$QMAKE_CFLAGS_LTCG
|
2015-09-02 18:48:51 +00:00
|
|
|
QMAKE_CXXFLAGS_DISABLE_LTCG = $$QMAKE_CFLAGS_DISABLE_LTCG
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_LINK = xilink
|
|
|
|
QMAKE_LFLAGS = /NOLOGO
|
|
|
|
QMAKE_LFLAGS_RELEASE =
|
2016-06-16 19:22:55 +00:00
|
|
|
QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO =
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_LFLAGS_DEBUG = /DEBUG
|
2014-06-26 21:56:06 +00:00
|
|
|
QMAKE_LFLAGS_LTCG = $$QMAKE_CFLAGS_LTCG
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2013-03-14 23:42:15 +00:00
|
|
|
QMAKE_LIB = xilib /NOLOGO
|
2011-04-27 10:05:43 +00:00
|
|
|
|
2013-03-14 23:42:15 +00:00
|
|
|
DSP_EXTENSION = .dsp
|
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
|
|
|
|
2017-05-04 08:15:23 +00:00
|
|
|
include(../common/angle.conf)
|
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
|
|
|
|
2014-03-03 19:41:52 +00:00
|
|
|
load(qt_config)
|