<p dir="ltr">Hi I am traveling right now and will not be able to properly read this until tomorrow sorry.<br>
Scarlett </p>
<div class="gmail_quote">On Oct 22, 2015 8:39 PM, "Holger Kaelberer" <<a href="mailto:hk@elberer.de">hk@elberer.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
On 21.10.2015 01:16, Holger Kaelberer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Merged with master.<br>
<br>
Note for all devs:<br>
<br>
There is a git submodule on master now. Therefore after git pull-ing do an initial<br>
<br>
git submodule init && git submodule update<br>
<br>
before building.<br>
</blockquote>
<br>
This submodule broke the CI builds of gcompris and I got some feedback on it from Ben [1].<br>
<br>
To sum up: For packaging to always and only rely on an external dependency like we do atm is not what packagers and ci-admins prefer.<br>
<br>
qml-box2d was made a submodule and is built automatically to make handling convenient for developers. I expected that we need to adjust the current build once GCompris-qt is upstream in some distribution's package repo. If we have to change building again now for ci, let's agree upon how we do it first.<br>
<br>
That's the status quo:<br>
<br>
- Right now the qml-box2d dependency is contained as git submodule and automatically built in the build-dir and installed into INSTALL_PREFIX/lib/qml. Without the submodule being checked out the build fails.<br>
<br>
- On desktop: Most distros (checked ubuntu, FC) don't package qml-box2d (in the version we need it). So right now we need to  provide the plugin in an installation/runtime. Devs need to compile(+install) it for building and testing.<br>
<br>
- On android (and the other experimental targets) there is of course no other way than to package the plugin in an apk. At build time it needs to be present somewhere, if it is installed below the system's QML2_IMPORT_PATH it gets pulled into the apk during build.<br>
<br>
- Same probably for CI (builds afaik only linux/gcc atm): the module needs to be present somewhere in the env.<br>
<br>
According to Ben the preferred way for packaging as well as for ci is to set up the build-env properly (injecting the dependency) prior to building gcompris itself.<br>
<br>
The same would probably be the case for a packaging scenario where qml-box2d would be provided as a package. (Correct me if I'm wrong)<br>
<br>
Options we have:<br>
<br>
1. Remove the submodule/automatic build completely and leave it to the developer/ci/packager set up his build-env properly. That's what I wanted to avoid when I added the submodule. In this case the dev would need to clone qml-box2d + qmake && make && make install it for each target platform/Qt target he wants to build for. Once installed the module is in place.<br>
Not sure if this is possible for packaging as the installed dependencies must be pulled into the package then.<br>
<br>
2. Make the build optional with somehting like -DBUILD_QML_BOX2D. The default would be to let it fetch from the system/env and error out if it is not found. In this case a developer would still have the option to let it build automatically if passing -DBUILD_QML_BOX2D<br>
<br>
2.a) As 2 but with inverted default: Build per default the dependency and let it switch off with something like -DUSE_SYSTEM_QML_BOX2D. In this case the ci/packager would need to pass the build-switch.<br>
<br>
3. As 2 but remove the submodule and turn the dependency into a cmake ExternalProject directly pulling in from a remote git-URL. At build-time the dependency would then get cloned into the build-prefix and build automatically. This gets rid of the submodule stuff with the overhead of needing to clone once for each build-location and target.<br>
<br>
3.a) As 2.a but with ExternalProject instead of the submodule.<br>
<br>
4. Build and link qml-box2d statically to gcompris, should be possible if the module is registered manually at app startup. This would solve all problems at runtime, but smells like hacking around missing dynamic dependencies.<br>
<br>
Personally I'd vote for 2 which leaves all options while defaulting to what seems to be packaging conventions.<br>
<br>
What do you think?<br>
<br>
CCing Ben, Scarlett and Bruno, feedback appreciated.<br>
<br>
Thanks,<br>
  Holger<br>
<br>
[1] <a href="https://sysadmin.kde.org/tickets/index.php?page=tickets&act=view&id=BJR-9730" rel="noreferrer" target="_blank">https://sysadmin.kde.org/tickets/index.php?page=tickets&act=view&id=BJR-9730</a><br>
</blockquote></div>