summaryrefslogtreecommitdiffstats
path: root/qtwebengine.pro
Commit message (Collapse)AuthorAgeFilesLines
* Let Qt decide whether to build the examplesAndras Becsi2014-10-201-6/+0
| | | | | | | | Remove old workaround, since because QtWebEngine is already part of Qt 5 and we do no longer need to force building the examples. Change-Id: If6c0d2ba07c59c4965142274b5802b1ed18fe418 Reviewed-by: Michael Bruning <michael.bruning@digia.com>
* Deploy QtWebEngineCore as a Qt moduleJocelyn Turcotte2014-03-071-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This delegates the linking step from ninja to qmake so that we can let qmake decide the destination of the target itself, easing the deployment and installation logic across platforms. The module is only deployed as a binary and no header are available outside of the source tree. This is only to make sure that the dependence of the QtWebEngine and QtWebEngineWidgets libraries on it is resolved at runtime exactly the same way as with other Qt modules, on all platforms. Ninja still takes care of the compilation and gyp lets qmake know how and what to link by dumping the list of flags and input files in a generated .pri file. This has to be done in a separate .pro file so that we can make sure that ninja is run inconditionally before make reaches the dependency check in core_module.pro, ensured by the parent Makefile. Note 1: This patch removes RPATH hacks that are no longer necessary Note 2: Other targets like ffmpegsumo are still linked by ninja. The same logic could be moved to a qmake file but this require some more work to make sure that some switches (e.g. -stdlib=libc++) are coordinated between gyp and qmake. Change-Id: If65968547bde5b9cf732e31e97931c17ae1921a7 Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Don't try to build examples if RPATH isn't availableJocelyn Turcotte2014-02-261-4/+8
| | | | | | | | | | | QMAKE_LFLAGS_RPATH is stripped from the mkspecs in official Arch Linux Qt packages. Don't force building examples in this case to allow qtwebengine to build using the system Qt with a straight qmake;make. Change-Id: Id406d55d34c0d313d69ba9f689f8f24f33038824 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Make sure examples are always builtSimon Hausmann2014-02-081-0/+7
| | | | | | | | | | | When building against Qt 5 release binaries, QT_BUILD_PARTS does not include examples. However we want to unconditionally build examples, until we become part of the Qt 5 module set. (cherry picked from commit f2fb23f23f67db841467752c2a4c2a5cb9ebde43) Change-Id: I6239c3f9280c50f5418947f711924be59265c4ce Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Moving sources to src part 2: Adjust paths.Jocelyn Turcotte2013-11-281-0/+1
| | | | | | | | | | | | | | | | | | | NOTE: To build after this you should rerun init-repository.py 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 lib.pro. This file has also been split into src.pro and core.pro. Change-Id: Ieee9158a65f526b15244eaca59e779b7069d337e Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Moving sources to src part 1: Move files.Jocelyn Turcotte2013-11-281-64/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This only move files without adjusting any paths. This moves: - lib/quick -> src/webengine/api (API files) lib/quick -> src/webengine (other files) This contains the main QtWebEngine module library since <ec7b2ee70a8b2db7fb87f50671a001ddd54697b0>. - lib/widgets -> src/webenginewidgets Also rename this directory to match its module name and rename Api to api. - lib -> src/core - process -> src/process - resources -> src/core/resources - tools/* -> tools/scripts/ The build directory is spread as follow: - build/build.pro -> src/core/gyp_run.pro - build/qmake_extras/* -> src/core/ (for the host and target .pro files) - build/qmake -> tools/qmake - Build related scripts -> tools/buildscripts Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Get rid of the intermediate "shared" static library.Jocelyn Turcotte2013-11-211-3/+1
| | | | | | | | It is not necessary anymore since QtWebEngineProcess dynamically links to the core library which will now contain those symbols. Change-Id: I3475347bab41a00b943f934a5e341326c66dc726 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Make QtWebEngineProcess a slim executable.Jocelyn Turcotte2013-11-211-2/+2
| | | | | | | | | | | Move all the process code in the core library and let the later simply call its QtWebEngine::processMain exported function from its main. This also allows us building QtWebEngineProcess directly with qmake without going through gyp. Change-Id: I8df36510d0bf14e313918bef807e2118f1ecadd5 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Add a WebEngine.experimental QtQuick plugin library.Jocelyn Turcotte2013-11-181-3/+7
| | | | | | | | | | | | Bring this QtWebKit concept to our API as well to contain APIs that we aren't comfortable adding to the supported-forever group yet and allow trying them out unofficially for an undetermined number of releases first. Change-Id: I52c8655dfd2996ea461ac6c00de975002827a4c3 Reviewed-by: Andras Becsi <andras.becsi@digia.com> Reviewed-by: Arvid Nilsson <anilsson@blackberry.com> Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Add an intermediate Qt5WebEngine module library.Jocelyn Turcotte2013-11-181-6/+10
| | | | | | | | | | | | | | | | | | Make the WebEngine QtQuick plubin library a library only that fetches the API privatly from the official module. This will allow an experimental plugin library to also have access to the API classes, which it currently can't since the plugins aren't deployed the same way as module to <prefix>/lib. The module currently only export classes privately but the plan is to make this library the official linking point of entry for applications along with the Qt5WebEngineWidgets module. The WebEngineCore library could eventyally be merged into this module library if we can get gyp to play well with qmake. Change-Id: I5edb60b412e213b59f791a7b8df9f28c295502de Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Fix qmake -r by moving load(qt_parts) to the end of the projectAndras Becsi2013-11-151-2/+3
| | | | | | | | | This is an issue for non-developer builds of Qt where the forwarding headers have to be generated before processing the examples project files. Change-Id: I683227c97a763c48b8ab090580f37f7134680c59 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Use explicit dependencies to specify build orderAndras Becsi2013-10-251-10/+31
| | | | | | | Explicit dependencies make proper parallel builds possible. Change-Id: I71f7d7fbee1244490dfcb040bb4145ab74d5c416 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Build fix for the Widgets tests can be running by make check.Adam Kallai2013-10-161-3/+2
| | | | | Change-Id: Ic5ec80679f19235f441108e99e06d489ff2cabc3 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Rename findNinja to findOrBuildNinja and fail early if gyp failsAndras Becsi2013-10-011-1/+1
| | | | | | | | | We should not not use the $$ syntax to collect the output of the gyp call instead we should just fail with an error in case gyp_qtwebengine fails. Change-Id: Ib6218bdfb998100a3717470713ed5bf5f30db339 Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Allow overriding target compiler and linker with qmake's oneAndras Becsi2013-10-011-1/+2
| | | | | | | | | | | | Using make_global_settings, we can pass along the compiler and linker that qmake uses, still allowing overriding it through environment variables. We generate qmake_extras.gypi and populated with the host and target compilers so that it also works when cross compiling. Based on patch by Pierre Rossi <pierre.rossi@digia.com> Change-Id: Ia3789abeea88f4d3cde75c2cf07cc9de66d7afbf Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* API tests: Make them link.Jocelyn Turcotte2013-08-201-1/+6
| | | | | | | | | Add the tests to the build. Very few of the test cases pass already, but this should allow to progress on the implementation while fixing/unskipping those tests. Change-Id: Id96d22748f8effad963232c2451fb8719d299fee Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Split out the Widgets and QtQuick integrationPierre Rossi2013-07-311-1/+5
| | | | | | | | | | | | | | | 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 <jocelyn.turcotte@digia.com>
* Add a python script to generate the chromium .pak resource files.Zeno Albisser2013-07-181-1/+2
| | | | | | | | This is necessary, because the pak files must be available when qmake checks for the dependencies for RESOURCES in lib.pro. Change-Id: Ia173c70746402b2fee09bfa035a9f8780e88cc94 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Split out the example into two distinct onesPierre Rossi2013-06-171-1/+1
| | | | Cleaner than deciding on startup with an env variable
* Make ninja detection a bit more robustPierre Rossi2013-06-141-2/+5
| | | | | | | | Having ninja in the PATH should be good enough. If that didn't work, we try to find it in the most logical location relative to CHROMIUM_SRC_DIR and bail out otherwise. Since it seems unlikely to vary, and can be convenient to keep persistent, we put it in .qmake.cache if qmake uses a cache.
* Rename remaining references of blinq to QtWebEngine.Jocelyn Turcotte2013-06-111-0/+23