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

[Holger Kaelberer]

Hi,

thanks all for your feedback.

On 23.10.2015 10:58, Ben Cooksley wrote:
> On Fri, Oct 23, 2015 at 7:39 AM, Holger Kaelberer <hk at elberer.de> wrote:
>> Hi
>
> Hi Holger,
>
>>
>> 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.
>
> The other option is: If the local copy of it exists, go ahead with
> trying to use that, otherwise try to find a system wide copy.

Implemented that one but with inverted order: Per default use a system-installed module if available 
and automatically fall back to the submodule build. (-DQML_BOX2D_MODULE=auto, default) Rationale: if 
a module is there (either installed manually or from a package) there is no need to build it 
again-and-again...

While still having the options to enforce either way:

-DQML_BOX2D_MODULE=system
  Presupposes a module installed on the system and errors out if it is not there.

-DQML_BOX2D_MODULE=submodule
  Always build the module from the git submodule and install the result.

In case the submodule is built, it is init-ed && update-d on-the-fly, which still makes lazy devs as 
well the CI happy.

Pls raise your hand if anybody encounters problems with.

Thanks,
   Holger

>
> That way developers, your Android builds, etc. can initialize the
> submodule and go ahead as they do now - but it doesn't trouble
> packagers or the CI system who provide it through their conventional
> means.
>
>>
>> Thanks,
>>    Holger
>
> Cheers,
> Ben
>
>>
>> [1]
>> https://sysadmin.kde.org/tickets/index.php?page=tickets&act=view&id=BJR-9730