| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Set the LSUIElement key as Chromium does in its helper app's
Info.plist to prevent seeing a jumping icon in the dock while the OS
waits in vain for QtWebEngineProcess to create a window.
Change-Id: I6c836621ec506fde04bc3825f64c49630a065351
Task-number: QTBUG-42955
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until we can rely on Qt using @rpath on OSX, QtWebEngineProcess'
dependencies must either be updated by macdeployqt when creating
an .app bundle, either we must make that path relative at build
time.
Since QtWebEngineProcess.app is always deployed inside
QtWebEngineCore.framework, we can safely assume that the dylib is
always in a parent directory and that QtCore.framework can be found
one directory higher.
The additional dependencies of QtWebEngineCore.framework will be
handled by the dynamic linker when it gets loaded, but this only
works for QtWebEngineProcess when macdeployqt uses @loader_path
instead of @executable_path (then relative to the application which
is in a different directory than QtWebEngineProcess).
This can be forced by passing a non-empty value for its
-executable= command-line argument (e.g
`macdeployqt Browser.app -executable=Browser.app/Contents/MacOS/Browser`)
All this will be much simpler once we got Qt framework builds to use
@rpath instead in a future minor version.
Task-number: QTBUG-41611
Change-Id: Ied46c65a09f7033b622708da6e3d85855f9abf34
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently no convenient way to deploy QtWebEngine into an application
bundle on OSX. macdeployqt copies frameworks into a .app bundle's Frameworks
directory but this makes no sense unless all the needed files are also
distributed with the bundle.
This patch moves:
- The ffmpegsumo.so library into Libraries/
- Locale .pak files, qtwebengine_resources.pak and icudtl.dat into Resources/
- QtWebEngineProcess into its own .app bundle, itself into Helpers/
QMAKE_BUNDLE_DATA is used to copy files into the bundle while INSTALLS is
used when installing normally. A LOCALE_LIST is explicitly listed since
QMAKE_BUNDLE_DATA can't handle the * glob to match all source files.
Change-Id: I5c0df57b4b9e93f9cce34a74a6e024bf90d37b5c
Task-number: QTBUG-41611
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@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>
|
| |
|
|
|
|
|
|
|
|
| |
Adopt to toolchain changes and fix the build with the
current snapshot.
This patch adds some missing overrides and build system
configurations.
Change-Id: I488929500347bdb5a077ac14e9553cedfcaa605d
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
| |
|
|
|
|
|
|
|
| |
In developer (non-prefix) builds, the binary goes to $$MODULE_BASE_OUTDIR/libexec,
which is practically qtbase/libexec. In prefix builds it'll be linked to $module_toplevel/libexec
and installed into $prefix/libexec.
Change-Id: Ia42519f3113976e707fbda9e09dbf7ef6e235924
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@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
<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>
|
