path: root/.qmake.conf
Commit message (Collapse)AuthorAgeFilesLines
* Bump versionOswald Buddenhagen2015-06-291-1/+1
| | | | Change-Id: Iab691f393546e353948e744820dc7fdce9044bb9
* Update the version number to 5.5.0Jocelyn Turcotte2014-12-041-1/+1
| | | | | Change-Id: Ice525f351fab9db9208611a5b0efa04f5232365d Reviewed-by: Andras Becsi <>
* Use the same version scheme as other Qt modulesJocelyn Turcotte2014-09-111-3/+1
| | | | | | | | | | | | | | | | After trying to get rid of all private header includes, the last standing one is qplatformnativeinterface.h even though its name previously suggested that it isn't private. This would be a complicated piece to expose publically in a way both flexible and binary compatible, and is a task heavy enough to justify committing to follow Qt's release cycle. The QML import version remains to 1.0 and will be incremented the same manner as QtQuick itself does. Change-Id: I6fab5f229d9f79dbc7a3e82d65ad324020929863 Reviewed-by: Michael Bruning <>
* Hardcode the module version to not confuse syncqt.plMichael BrĂ¼ning2014-09-031-5/+1
| | | | | | | | | uses a combination of echo and sed to retrieve the module version. It cannot run qmake, which would be necessary for evaluating the version dynamically. Change-Id: Ibdd95da5dc26edf18f005ab7f82e83136acd795e Reviewed-by: Andras Becsi <>
* Update the library and QML version to 1.0Jocelyn Turcotte2014-08-121-1/+7
| | | | | | | | Also update all the examples to use 1.0 as 0.9 shouldn't be publically recommended. Change-Id: Ic58e35bdfd3a0f3d5201fc069b7103027ba84574 Reviewed-by: Andras Becsi <>
* Set the QtWebEngine modules version to 0.9.0Jocelyn Turcotte2014-05-161-2/+1
| | | | | | | | | | | | | | | | | | | | Also make sure that this version number appears in the user agent string and in the QML imports. The plan, unlike other Qt modules, is to keep our module and QML versions in sync to make it easy for developers to figure out what API is available in a given version. The QTWEBENGINECORE_VERSION_STR define is explicitly set in the .pro file since we don't call syncqt to generate a version header for the core module. The 0-major version currently causes the library name to start with libQt0 instead of libQt5, but this is something that we can fix in qtbase once we want to officially support linux desktop with QtWebEngine 1.0.0. Change-Id: I31915e84869b4db456416ef1f85a2296b8a06c99 Reviewed-by: Pierre Rossi <> Reviewed-by: Simon Hausmann <>
* Fix installation of most examplesSimon Hausmann2014-01-151-0/+1
| | | | | | | | | | * Make sure the example source code is installed * Make sure the installation path is consistent with the path within the module, to ensure that the sources end up next to the compiled binary. * Skip the widgets nano browser from the installation, as it's a developer tool. Change-Id: I35b421e12f8e6ddd3f2045e318b21543ff929cd8 Reviewed-by: Jocelyn Turcotte <>
* Moving sources to src part 2: Adjust paths.Jocelyn Turcotte2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | NOTE: To build after this you should rerun or run $> git submodule sync $> git submodule update $> git config qtwebengine.chromiumsrcdir src/3rdparty This makes everything build by adjusting paths. Other mixed-in changes: - Rename qtwebengine_src variables in scripts to qtwebengine_root to avoid confusion. - Cleanup the release and debug extra targets that were in This file has also been split into and Change-Id: Ieee9158a65f526b15244eaca59e779b7069d337e Reviewed-by: Zeno Albisser <> Reviewed-by: Pierre Rossi <>
* Split out the Widgets and QtQuick integrationPierre Rossi2013-07-311-3/+2
| | | | | | | | | | | | | | | This is the first step to making proper Qt Modules out of QtWebEngine. The Widgets integration becomes a proper C++ Qt Module while we make the QtQuick side a QML plugin for now (could probably be promoted if the need arises). Code-wise, this means the introduction of a WebContentsAdapterClient interface that is subclassed by the private implementation of our API classes for delegation of things that are UI specific. Functionality from WebContents and the like is exposed via the WebContentsAdapter. Change-Id: I4ca3395b9fe8502a24e36002cfd5af44067bb6e8 Reviewed-by: Jocelyn Turcotte <>
* New qmake approachPierre Rossi2013-04-291-0/+6
This should allow us to have much better integration by generating the necessary gyp files directly from qmake. Mostly works for now, though we will most likely need to build the gyp generation as we go. * Out dir logic is still crap and needs to be (re)worked. * In the same vein, we probably don't want the generated gyp content ending up in the source tree in the long run, which could prove tricky with relative paths to sources and all.