This fixes the build on OS X if the path to clang is not cached,
and only builds examples if Qt was configured to do so.
This has already been fixed in dev.

Change-Id: Ia2d17f38f30e832425f6e1cd014b46a6c6ae78ec
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>

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>

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>

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>

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 f2fb23f2

)

Change-Id: I6239c3f9280c50f5418947f711924be59265c4ce
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

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>

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
  <ec7b2ee7

>.
- 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>

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>

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>

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>

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>

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>

Explicit dependencies make proper parallel builds possible.

Change-Id: I71f7d7fbee1244490dfcb040bb4145ab74d5c416
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

Change-Id: Ic5ec80679f19235f441108e99e06d489ff2cabc3
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

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>

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>

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>

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>

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>

Cleaner than deciding on startup with an env variable

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.

process uses the same code as lib and decides at runtime which
code to run. Fix the debug build by making sure that all infrastructure
code is available in both process and lib by building common code
not shared directly through chromium sources in a separate static lib.

Change the semantics of getOutDir, introduce getConfigDir.
Rely on Gyp's configurations mechanism to get a sensible
path for the BLINQ_PROCESS_PATH in both cases.
Also make the build smarter in that re-generation of gyp files
will lead to re-gyping.

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.

We'll probably add a qmake wrapper for it later, but for now that should do.