| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Add proper support for GYPINCLUDES in gyp_generation.
Rename the exclusion gypi to a more generic name so we
can use it for more intrusive changes (we'll need it for mac).
Change-Id: Ie26f579c33d5e35b8c904fab9f448cde11bf0072
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
| |
Since ContentBrowserClientQt::OverrideCreateWebContentsView now
takes care of using our Qt layer at runtime without relying on
the static RenderWidgetHostView::CreateViewForWidget, we can
now avoid linking this layer into the render process.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
technically it's more correct now that we don't even bother and
generate the .gyp file directly.
|
|
|
|
|
|
|
| |
This way we won't have to define the BLINQ_PROCESS_PATH environment variable
except in the case where we want to override that value.
Refactored some of the output dir logic in the process
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We need to replace this with a properly dynamically generated list
of dependencies, but for prototyping this will have to do the trick.
|
|
|