[Tinkerphones] [Gta04-owner] QtMoko2 again...
josua.mayer97 at gmail.com
Thu Oct 26 12:40:21 CEST 2017
Hi Jonas, Nikolaus,
Am 26.10.2017 um 11:11 schrieb Jonas Smedegaard:
> Quoting H. Nikolaus Schaller (2017-10-26 07:05:10)
>>> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard <jonas at jones.dk>:
>>> Quoting H. Nikolaus Schaller (2017-10-25 17:44:50)
>>>> Back to the original problem: I had not expected that there is a
>>>> need for a configure-make-install. Since we are fully Debian.
>>> How do you mean configure-build-install isn't needed? QtMoko is
>>> compiled code, so will need to be compiled.
>> But you shouldn't have to to type configure & make to start the
>> dpkg-buildpackage wrapped by a makefile.
>> The dpkg-buildpackage of course must do a configure & make for the
>> source tree, but hide that from the user.
>> IMHO, something is done here upside down.
>> My initial mistake was to assume that I can directly call
>> dpkg-buildpackage after unpacking the source tree. It turned out that
>> this does not work. At least not without modifications.
> If you expect source to be a Debian source package¹ then I agree it must
> be be buildable by a) simply unpacking it (dpkg-source -x *.dsc), b) cd
> into root of unpacked source tree, and c) build it (dpkg-buildpackage).
> But a large project involving embedded (likely multiple interlinked)
> libraries cannot sensibly² be organized as a single(!) Debian source
> package - each library should be a separate source package, built and
> tested and packaged and versioned on its own.
> I thought that your labeling it "upside down" meant that you think it
> should be adjusted to be able to compile with a single dpkg-buildpackage
> call. I disagree with that: I believe that the sensible way to turn
> such a set of essentially multiple sources is to unentangle those into
> multiple Debian source packages and build each of those separately.
> If untentangling into multiple Debian source packages was also what you
> talk about I do believe that untentangling into multiple Debian source
> packages is what Joshua intend to (eventually, when better understood)
> reach at. If that is also what you are talking about above, then I
> simply suggest to not label it as "upside down" which can be
> misunderstood as the _build_ routines_ need fixing when really it is
> more fundamentally the _source organization_ which need fixing (too).
> A more descriptive labeling would in my opinion be "a big mess".
> ¹ Source format "1.0" is upstream tarball + Debian diff + dsc file, and
> source format "3.0 (quilt)" is upstream tarball + Debian tarball + dsc
> ² Indeed, Chromium is *not* a sensibly organized source package!
>>>> It should even be possible to use apt-source -b - if we have proper
>>>> source packages. So it looks as if the build architecture of QtMoko
>>>> is upside down...
>>>> Maybe it is historical since this is still Squeeze and Wheezy code
>>>> and multiarch wasn't complete back then. On Jessie or Stretch I
>>>> think it could be much simpler if the debian/rules are updated.
>>> I believe the reason QtMoko build routines fit badly with Debian
>>> style of packaging is that it does not use existing shared Qt
>>> libraries but instead embeds its own fork of Qt optimized for
>>> embedded devices: https://en.wikipedia.org/wiki/Qt_Extended
>> It could be a renowned Debian citizen if it would not embed it but
>> just package and provide the special QtE libraries and then just use
>> the -dev version for dpkg-building the launcher, dialer, etc. This is
>> what Josua is working on:
> I guess that this:
> "if it would not embed it"
> expands to this:
> "if QtMoko project would not embed QtE libraries"
> and then we agree - except for the word "just": Joshua reports that
> there are trouble unentangling them because their interdependency seems
> to form a circular graph.
Not really. The configure script of qtmoko sets up a ton of qmake
projects, *one* of them being a build of Qt itself. The only thing
special about that Qt appears to be that it is built to use the
framebuffer directly for drawing.
In the past I have tried to build and package Qt standalone, and have
the qtmoko configure script find that existing qt. However there was
always some weird error message in a deeply hidden piece of either
configure(written in perl), qmake.pro, or more weird files referenced by
It is those build preparation files that also include a recursive call
of configure to itself with different arguments. I guess this is the
circular thing you remember.
Otherwise qtmoko should be a component based project, producing a bunch
of shared libraries, the qtmoko application, and a bunch of additional
I expect these to be organizable as individual qmake projects
referencing each others as dependencies, and called by a central qmake
> - Jonas
More information about the Community