summaryrefslogtreecommitdiffstats
path: root/src/process/process.pro
Commit message (Collapse)AuthorAgeFilesLines
* OS X: Fix QtWebEngineProcess @rpath handling so macdeployqt works.Alexandru Croitor2016-02-251-16/+2
| | | | | | | | | | | | | | | | | When QtWebengineProcess was built on OSX using frameworks, all linked frameworks were found using @executable_path, except for QtPositioning which still used @rpath, and the run path list did not contain an entry to point to the main app bundle frameworks directory. Make sure all frameworks use @rpath, and also add a run path value pointing to the main app bundle frameworks directory, so all frameworks can be found once deployed with macdeployqt. Change-Id: Ie25f4c15169bd608dd819294901c196a7d794f43 Task-number: QTBUG-50155 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com> Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com> Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
* Revert "Remove rpath workaround from QtWebProcess build."Michael Bruning2015-10-301-1/+16
| | | | | | | | | | | It does not work properly with the new rpath logic and causes problems with the installer packages. This should be a temporary fix until the rpath situation has been cleaned up again. This reverts commit 819279827a4ce05562909994468ec5604392c672. Change-Id: I082ba0118d410f90d202c786d07717bf224d5f70 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-281-0/+5
|\ | | | | | | | | | | | | Conflicts: src/3rdparty Change-Id: I49acdd9b5ca94f2807b0c13a97f508a67f1c5750
| * make the render process DPI-awareJoerg Bornemann2015-10-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, system calls that retrieve screen properties (like GetSystemMetrics to get the size of a scroll bar button) are dependent on the DPI awareness setting of the calling process. The render process must use the same DPI awareness setting as the browser process. Retrieve the DPI awareness of the parent process in the render process and set it accordingly. Task-number: QTBUG-48380 Change-Id: Ic17d29d0f584e3cf230ac6ea2b08e3aa0d87ccdd Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* | Remove rpath workaround from QtWebProcess build.Jake Petroules2015-09-061-17/+1
|/ | | | | | | | | This also fixes a runtime failure when building the webengine module independently (for example, where QtCore and QtWebEngine* frameworks are located in different directories). Change-Id: I801d74da0be495089bf552b85b507918684b9685 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* Make QtWebEngineProcess use full 4 GiByte of memoryKai Koehne2015-08-031-0/+2
| | | | | | | | | | Pass /LARGEADDRESSAWARE the the MSVC linker to allow allocating more than two GiByte of memory for 32 bit. The flag is a NOOP for 64 bit. Task-number: QTBUG-47129 Change-Id: I82c4a7bc99e9042c4901425b37202d7977c0bcaa Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
* Deploy QtWebEngineProcess.exe at library executables path on WindowsPeter Varga2015-04-151-1/+2
| | | | | | | | | | Use the proper library executables path on Windows instead of the libexec. With this fix it is not necessary to set QTWEBENGINEPROCESS_PATH environment variable per default. Change-Id: I8cce07b8adbccc88b03c9cf942841eb1d4a5f176 Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
* Ensure QtWebEngineProcess is built in release modeAndy Shaw2015-02-031-1/+1
| | | | | | | | | | If debug_and_release is set then QtWebEngineProcess should be built in release mode as it is a separate process and when it is deployed later it will be in the right mode already. Change-Id: I377baa20f01b70db91a7a1cec5f1014b44780546 Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* OSX: Don't show QtWebEngineProcess in the dockv5.4.0Jocelyn Turcotte2014-12-021-0/+3
| | | | | | | | | | | 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>
* Use a relative install_name for QtWebEngineProcess' dependenciesv5.4.0-rc1Jocelyn Turcotte2014-11-201-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Deploy external data in QtWebEngineCore.framework for framework buildsJocelyn Turcotte2014-11-061-4/+12
| | | | | | | | | | | | | | | | | | | | | 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>
* Deploy QtWebEngineCore as a Qt moduleJocelyn Turcotte2014-03-071-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix the embedded buildAndras Becsi2014-02-051-1/+2
| | | | | | | | | | 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>
* Fix placement of webengine processSimon Hausmann2014-01-151-2/+2
| | | | | | | | | 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>
* Moving sources to src part 2: Adjust paths.Jocelyn Turcotte2013-11-281-1/+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-0/+21
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 06:16:10 +0000