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.