[GCompris-devel] HEADS UP: git submodule on master

[Bruno Friedmann]

On Thursday 22 October 2015 10.46:36 Scarlett Clark wrote:
> Hi I am traveling right now and will not be able to properly read this
> until tomorrow sorry.
> Scarlett
> On Oct 22, 2015 8:39 PM, "Holger Kaelberer" <hk at elberer.de> wrote:
> 
> > Hi
> >
> > On 21.10.2015 01:16, Holger Kaelberer wrote:
> >
> > Merged with master.
> >>
> >> Note for all devs:
> >>
> >> There is a git submodule on master now. Therefore after git pull-ing do
> >> an initial
> >>
> >> git submodule init && git submodule update
> >>
> >> before building.
> >>
> >
> > This submodule broke the CI builds of gcompris and I got some feedback on
> > it from Ben [1].
> >
> > 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.
> >
> > 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.
> >
> > That's the status quo:
> >
> > - 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.
> >
> > - 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.
> >
> > - 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.
> >
> > - Same probably for CI (builds afaik only linux/gcc atm): the module needs
> > to be present somewhere in the env.
> >
> > 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.
> >
> > 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)
> >
> > Options we have:
> >
> > 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.
> > Not sure if this is possible for packaging as the installed dependencies
> > must be pulled into the package then.
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> > 3.a) As 2.a but with ExternalProject instead of the submodule.
> >
> > 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.
> >
> > Personally I'd vote for 2 which leaves all options while defaulting to
> > what seems to be packaging conventions.
> >
> > What do you think?
> >
> > CCing Ben, Scarlett and Bruno, feedback appreciated.
> >
> > Thanks,
> >   Holger
> >
> > [1]
> > https://sysadmin.kde.org/tickets/index.php?page=tickets&act=view&id=BJR-9730
> >

The option 2 and eventually 2a is what I saw the most in packaging.


-- 

Bruno Friedmann 
Ioda-Net Sàrl www.ioda-net.ch
 
 openSUSE Member & Board, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot