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 <jo...@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. >> Indeed. >> >> 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 > file. > > ² 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: >> >> http://git.goldelico.com/?p=qtmoko2-qte.git;a=summary > 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 qmakefiles. 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 applications. I expect these to be organizable as individual qmake projects referencing each others as dependencies, and called by a central qmake subdirs project. > > > - Jonas > _______________________________________________ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
