Review Request 109503: Compile with current qt dev branch

[Ben Cooksley]

On Sun, Mar 17, 2013 at 10:35 PM, David Faure <faure+bluesystems at kde.org> wrote:
> On Sunday 17 March 2013 20:58:08 Ben Cooksley wrote:
>> On Sun, Mar 17, 2013 at 12:59 AM, Stephen Kelly <steveire at gmail.com> wrote:
>> > Ben Cooksley wrote:
>> >> I tried the command invocation:
>> >> git submodule foreach 'git fetch; git reset --hard origin/dev || git
>> >> reset --hard origin/master || true'
>> >>
>> >> Which does do the job. However, as feared Jenkins is far too clever
>> >> and overwrites that completely, checking out the directories specified
>> >> in the .gitmodules file.
>> >
>> > Ok, thanks for trying it.
>> >
>> >> This means we need to construct a completely synthetic .gitmodules
>> >> file (which will then cause Jenkins to do the work of ensuring the
>> >> right branches are checked out) I suspect. Anyone got any other ideas?
>> >
>> > If that's an option for you it would be cool. I can't think of a better
>> > idea.
>>
>> I have now implemented this - although in a slightly different manner.
>>
>> Rather than running this before the SCM update phase Jenkins carries
>> out, I run this as part of the actual build process - in the part
>> where the repository has it's sources cleansed and any special
>> build.kde.org patches applied.
>
> I am rather surprised by all this. qt5.git exists in order to give us a
> version of each submodule which has been proven to work together, and instead
> of that we want to randomly check out "latest dev" for each module, even if
> that breaks? It also means that people working on KF5 will need to constantly
> update and recompile their Qt, instead of using less frequent updates to
> qt5.git. I know that right now it's lagging behind a bit too much, but as I
> said, that's being worked on, so switching to something completely different
> which will give us more grief doesn't seem very wise to me.
>
> It also means our instructions for contributors to KF5 are broken again,
> right? (using qt5.git not good enough anymore).
>
> I don't like how this requires everyone to constantly update qt5.

Me neither - it also requires extra code on the build.kde.org side to
complete and makes it hard for others to reproduce it's build results.
I only implemented it as it was requested on this list.

The root cause of this issue is the divergence between people who use
qt5.git and those who build the individual submodules separately.
Not helping matters is source incompatibility in Qt.

Long term we either need:
1) A commitment from the Qt project to make keeping qt5.git updated a
high priority (block all new commits from entering any submodule until
the issues in question are fixed for instance) or
2) We need to decide to adopt either qt5.git or individual submodules
as our only supported build option.

Regards,
Ben

>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by BlueSystems and KDAB to work on KDE Frameworks
>