Common changes to mingw-w64, ICC on Windows, and MSVC toolchains:
- set similar order of variables and its splitting into sections,
- set similar order of flags in variables and the way they are set.
mingw-w64 toolchain:
- move 'gcc-base.conf' include before setting Windows specific
flags, similar to include 'msvc-desktop.conf' in ICC on Windows
toolchain; this leads to consistency with other toolchains
and allows to safely override common GCC variables with Windows
specific ones, when needed,
- move 'QMAKE_EXT_OBJ' and 'QMAKE_EXT_RES' variables to the linker
flags section, according to its purpose.
MSVC toolchain:
- set flags order in 'CONFIG' variable, similar to mingw-w64 toolchain.
Change-Id: I417cc8f7959c669dd504f2c5c11eb879a7989bd4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
mingw-w64 toolchain:
- remove 'QMAKE_CXXFLAGS_THREAD' variable definition, since
'QMAKE_CFLAGS_THREAD' variable not set for mingw-w64 toolchain.
ICC on Windows toolchain:
- remove 'QMAKE_LFLAGS', 'QMAKE_LFLAGS_RELEASE',
'QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO' and 'QMAKE_LFLAGS_DEBUG'
definitions, since they're properly set in 'msvc-desktop.conf',
- remove 'DSP_EXTENSION' variable, which doesn't occur anywhere else
within QtBase; its most recent search results relate to
Visual Studio 6.0 and Intel Fortran.
Change-Id: I2ce5c2c9e9ca2c09c1acfcf8c60381d318e8e380
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Common changes to mingw-w64, ICC on Windows and MSVC toolchains:
- update toolchains description similar to 'gcc-base.conf'.
Change-Id: Ie456c6cec86c0d1c0107ca84a0fa7855666df91e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
As Qt applications using OpenGL are linked against these libs, merging
them into QtANGLE by default (780105f906)
was a binary incompatible change. This change restores the default
behavior to the one before given change.
If the user wants the libraries to be merged, he can pass
combined-angle-lib to configure.
Task-number: QTBUG-60373
Change-Id: Iedbd3f2ce9284fdde924cfae8d915d6d5fef00db
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Neither the Intel compiler nor Visual C++ have a dedicated switch to
enable F16C support, like GCC and Clang do. So we used the AVX switch
for that in commit 8241d51f70, as it was
the closest, lowest denominator. That was incorrect and insufficient.
The Intel compiler silently miscompiles the intrinsics with -xAVX,
making calls to out-of-line functions like _mm_cvtps_ph, which don't
exist. So we actually have to use AVX2 support to generate correct code.
That might be a problem later, since Ivy Bridge supports F16C but not
AVX2.
Visual C++ is able to generate F16C code with just -arch:AVX.
Either way, since there's no dedicated command-line switch, there's also
no dedicated preprocessor macro. We're using __AVX2__ for both
compilers, as that's a sufficient condition to indicate a processor that
supports F16C.
Change-Id: I27b55fdf514247549455fffd14b205b8d8b86da7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The .pro file requires the QMAKE_CFLAGS_F16C to be set to something. So
set it to AVX, as the instructions require the VEX prefix anyway (ICC
has no dedicated option for just F16C).
Change-Id: I27b55fdf514247549455fffd14b171940afd35a2
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
For Android, Windows and xcb. Verified on Win10 with NVIDIA, Win10
with AMD, Android with Tegra K1, Android aarch64 with Tegra X1, and
Linux aarch64 with Tegra X1 (Jetson TX1, L4T).
Introduce QPA-based Vulkan library loader, core function resolver, and
instance creation support. In addition to creating a new VkInstance,
adopting an existing one from an external engine is supported as well.
The WSI specifics are hidden in the platform plugins. Vulkan-capable
windows use the new surface type VulkanSurface and are associated with
a QVulkanInstance.
On Windows VULKAN_SDK is picked up automatically so finding vulkan.h
needs no additional manual steps once the LunarG SDK is installed.
[ChangeLog][QtGui] Added support for rendering to QWindow via the Vulkan
graphics API.
Task-number: QTBUG-55981
Change-Id: I50fa92d313fa440e0cc73939c6d7510ca317fbc9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The AES instructions were first introduced with the Westmere shrink
(22nm) of the Nehalem architecture. The SHA instructions are still
pending on Intel architecture, but is available on AMD family 17h (gcc
argument -march=znver1).
Both features operate on SSE registers, so that's why the MSVC command-
line argument is the SSE2 one and the configure-time tests depend on
features.sse2.
The qmake feature names end in "ni" because "aes" and "sha" are too
simple and could clash with other uses. The QT_COMPILER_SUPPORTS_ macro
doesn't have the "NI" suffix because it has to match the GCC/Clang
predefined macro.
Change-Id: I445bb15619f6401494e8fffd149dbd1f862ff51c
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
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>
This warning does not make sense. it seems to trigger when in code like
the following in template functions:
auto x = 1, y = 2;
3373: nonstandard use of "auto" to both deduce the type from an
initializer and to announce a trailing return type
Other reports on the Internet indicate that no one understands what
triggers this warning and have just worked around it. Additionally, the
same warning exists on other compilers with the same text, so it's
likely come from the EDG front-end. This has been reported to Intel.
Change-Id: I73fa1e59a4844c43a109fffd148d45065ab69eff
Intel-Issue-ID: 6000164202
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
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>
Adapt the mkspec which was forgotten in change
b0ec05f27b.
Task-number: QTBUG-48431
Task-number: QTBUG-51686
Change-Id: Ie95e650de8b7a7027979ec637fb77c7f0357a598
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
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>
See https://software.intel.com/node/522852. There are options to turn
off LTCG and, on Linux, to enable/disable fat objects.
Change-Id: I42e7ef1a481840699a8dffff14003db5a9c95b83
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This is probably emitted in error in ICC 16.
warning #809: exception specification for virtual function
"QQmlEnginePrivate::~QQmlEnginePrivate" is incompatible with that of
overridden function "QObjectData::~QObjectData"
Change-Id: I7a21ba10770ba008bdc18f535502376e1d92520f
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).
Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
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>
it makes no sense to let every spec do that separately, as it's fixed
by the generator+shell.
putting it into a file which is loaded regardless of the spec also
allows us to remove the hardcoded fallbacks from qmake.
if somebody overrode the values in their spec for some weird reasons,
they'll need to override spec_post.prf.
shell-{unix,win32}.conf are now dummies and print warnings.
Task-number: QTBUG-37269
Change-Id: I66c24fb4072ce4d63fdbfc57618daa2a48fa1d80
Reviewed-by: Jochen Seemann <seemann.jochen@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
GCC currently requires fat object files for static libraries, since the
linker would otherwise not load the .o file from the archive at all and
the linking would fail with a lot of undefined references. Clang on
Linux also needs this, but it has no equivalent flag, so enabling LTCG
for Clang on static libraries will result in linker error.
This commit does not add support for enabling it in configure. It can be
enabled on a per-project basis by doing CONFIG += ltcg or by passing
-config ltcg to qmake's command-line.
Change-Id: I52cf99f1ed9f1701e23a3b457ba3502fd28126ce
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Unlike MSVC, ICC is capable of selecting each of the processor feature
levels, so let's define the right macros.
Version 9.1 is really old and not supported, so we don't need to keep
the old workaround.
The compiler has been complaining that option -GX is deprecated and will
be removed, so update it to use the same as MSVC does.
Change-Id: I4158fcf2331c1d27462bb1cb19725c7136efab4a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Intel compiler does support C++11 options on the command-line.
configure.exe will correctly try to run it, but the test would fail for
incorrect reasons.
First, we need to pass the option -Qstd=c++11 to enable it.
Second, on Windows, the GCC experimental define isn't defined, nor is
__cplusplus updated yet. So we have to rely on the Intel-specific macro.
Third, we need CONFIG += console so that the application succeeds in
linking against a main() function, as opposed to a WinMain one.
Change-Id: I8f3252189df4f8854a9d9aa2cd919c288d2df420
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since there was no extension specified for static libraries then it
would end up not being able to build Qt at all.
Change-Id: Iec9040640ba399544b86df27e370fcf23cabb4de
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Instead of checking for dynamicgl in QT_CONFIG, which is apparently
not possible, revert them and do it in opengl.prf instead.
Dynamic GL is Windows-only for the time being so this should be sufficient.
Change-Id: If293ea4c9b024df52257086c8b6250602a44724d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
The patch introduces a new build configuration on Windows which
can be requested by passing -opengl dynamic to configure.
Platforms other than Windows (including WinRT) are not affected.
The existing Angle and desktop configurations are not affected.
These continue to function as before and Angle remains the default.
In the future, when all modules have added support for the dynamic
path, as described below, the default configuration could be changed
to be the dynamic one. This would allow providing a single set of
binaries in the official builds instead of the current two.
When requesting dynamic GL, Angle is built but QT_OPENGL_ES[_2] are
never defined. Instead, the code path that has traditionally been
desktop GL only becomes the dynamic path that has to do runtime
checks. Qt modules and applications are not linked to opengl32.dll or
libegl/glesv2.dll in this case. Instead, QtGui exports all necessary
egl/egl/gl functions which will, under the hood, forward all requests
to a dynamically loaded EGL/WGL/GL implementation.
Porting guide (better said, changes needed to prepare your code to
work with dynamic GL builds when the fallback to Angle is utilized):
1. In !QT_OPENGL_ES[_2] code branches use QOpenGLFunctions::isES() to
differentiate between desktop and ES where needed. Keep in mind that
it is the desktop GL header (plus qopenglext.h) that is included,
not the GLES one.
QtGui's proxy will handle some differences, for example calling
glClearDepth will route to glClearDepthf when needed. The built-in
eglGetProcAddress is able to retrieve pointers for standard GLES2
functions too so code resolving OpenGL 2 functions will function
in any case.
2. QT_CONFIG will contain "opengl" and "dynamicgl" in dynamic builds,
but never "angle" or "opengles2".
3. The preprocessor define QT_OPENGL_DYNAMIC is also available in
dynamic builds. The usage of this is strongly discouraged and should
not be needed anywhere except for QtGui and the platform plugin.
4. Code in need of the library handle can use
QOpenGLFunctions::platformGLHandle().
The decision on which library to load is currently based on a simple
test that creates a dummy window/context and tries to resolve an
OpenGL 2 function. If this fails, it goes for Angle. This seems to work
well on Win7 PCs for example that do not have proper graphics drivers
providing OpenGL installed but are D3D9 capable using the default drivers.
Setting QT_OPENGL to desktop or angle skips the test and forces
usage of the given GL. There are also two new application attributes
that could be used for the same purpose.
If Angle is requested but the libraries are not present, desktop is
tried. If desktop is requested, or if angle is requested but nothing
works, the EGL/WGL functions will still be callable but will return 0.
This conveniently means that eglInitialize() and such will report a failure.
Debug messages can be enabled by setting QT_OPENGLPROXY_DEBUG. This will
tell which implementation is chosen.
The textures example application is ported to OpenGL 2, the GL 1
code path is removed.
[ChangeLog][QtGui] Qt builds on Windows can now be configured for
dynamic loading of the OpenGL implementation. This can be requested
by passing -opengl dynamic to configure. In this mode no modules will
link to opengl32.dll or Angle's libegl/libglesv2. Instead, QtGui will
dynamically choose between desktop and Angle during the first GL/EGL/WGL
call. This allows deploying applications with a single set of Qt libraries
with the ability of transparently falling back to Angle in case the
opengl32.dll is not suitable, due to missing graphics drivers for example.
Task-number: QTBUG-36483
Change-Id: I716fdebbf60b355b7d9ef57d1e069eef366b4ab9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
There have been fixes done to the MSVC qplatformdefs.h that aren't
reflected in the ICC one -- specially the inclusion of
windows.h. Since ICC is never tested, simply defer to the MSVC one and
hope it's enough.
Task-number: QTBUG-30839
Change-Id: I3c22638cc7fac3399d3606b1583608e95208df6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Replace all tabs with proper space characters and consistently align
the '=' characters. The default alignment for the '=' of 25 characters
has been left as is to get a minimal diff. Lines with the '=' further
to the right and those belonging to 'proper code (TM)' have not been
touched.
The work was mostly done using the following python script (might
come in handy again...):
import sys, re
indent_eq = 25 + 0*4 # 25 characters was the most widely used indentation for the '=' character
p = re.compile(r'(\w+)[ \t]*([\-\+]?)(=$|= )[ \t]*(.*$)')
for fn in sys.argv[1:]:
with open(fn, 'r+') as f:
lines = []
nl_count = 0
continuity_indent = None
for l in f:
m = p.match(l)
nl = l
if m:
n_spaces = max(m.start(3), indent_eq - 1) - len(m.group(2)) - len(m.group(1))
if m.group(2) and m.start(2) >= indent_eq-1 and m.start(2) % 4 == 0:
n_spaces -= 1 # left-shift '+=' by one if the '+' is aligned to a multiple of 4
n_spaces = max(1, n_spaces) # we want at least one space before '='/'+='
nl = m.group(1) + ' '*n_spaces + ''.join(m.group(2,3,4)) + '\n'
continuity_indent = nl.find('= ') + 2 if l[-2] == '\\' else None # remember indent on '\\$'
elif continuity_indent:
nl = ' '*continuity_indent + l.lstrip()
if l[-2] != '\\': # check when to stop the continuation
continuity_indent = None
elif l.startswith('#'):
nl = l.expandtabs(2)
if l != nl:
nl_count += 1
lines.append(nl)
if nl_count > 0:
print fn, nl_count, len(lines)
f.seek(0)
f.writelines(lines)
f.truncate()
Change-Id: I1d2870d0a2fe2e30d398c140fe523e69dd20c81b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The printer support API has moved to printsupport module/plugins
Change-Id: I6fdc6c08e600d0f7cc8d79bef808227b54880904
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
on the way to eliminate scoping based on the spec.
gcc and msvc go as such into CONFIG, the other ones get the vendor
prefixed, as most are mostly unknown and thus likely to clash with
users' flags.
Change-Id: Ie622f53d90e96dbf05ce7d8c638cd355f04fa20c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
"CONFIG += qt warn_on release link_prl" is in every single spec (though
for link_prl there is one genuine exception and two apparent omissions).
Change-Id: I72e1e315586af828eefa3b0b70998ab892ec3c1a
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
there is no reason whatsoever to duplicate this so many times, and even
less reason to have specs with a deviating default.
Change-Id: Ia25836c079580adebc373697b8bd03598f79c69b
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
not strictly necessary, but nicer.
QMAKE_PLATFORM (and thus CONFIG) now also contains the name of the OS, and
its family (if applicable, e.g., bsd). this also adds more feature search
paths.
Change-Id: I3ab971e6e3b2b32cae53b95e4bc67a86688bc5cb
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
