From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: qt: monolithic or modular? Date: Fri, 20 May 2016 13:56:56 +0200 Message-ID: <87shxdgcxj.fsf@gnu.org> References: <20160405072220.1d828a86@debian-netbook> <20160518121757.GD13276@debian-netbook> <87a8jmw8fo.fsf@gnu.org> <20160519131750.GA8287@debian-netbook> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3j3A-000843-P6 for guix-devel@gnu.org; Fri, 20 May 2016 07:57:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3j37-0002oX-J5 for guix-devel@gnu.org; Fri, 20 May 2016 07:57:04 -0400 In-Reply-To: <20160519131750.GA8287@debian-netbook> (Efraim Flashner's message of "Thu, 19 May 2016 16:17:50 +0300") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Efraim Flashner Cc: guix-devel@gnu.org Efraim Flashner skribis: > On Thu, May 19, 2016 at 02:15:07PM +0200, Ludovic Court=C3=A8s wrote: >> Efraim Flashner skribis: >>=20 >> > On Tue, Apr 05, 2016 at 07:22:20AM +0300, Efraim Flashner wrote: >> >> I try very hard to not build qt on my laptop, mostly because of the l= ong build time (7 hours on hydra [0]). Currently we download and use the bi= g download of qt[1] and frankly I'd rather not. Qt does also ship in smalle= r bits[2], 32 if I counted correctly. I propose we package the submodules a= nd over time we go through the packages that use qt and switch out the mono= lithic qt for just the parts that the program actually uses. It makes it le= ss daunting to build, should make the closures smaller, and means that if a= submodule fails to build on an architecture then they only lose that modul= e, not all of qt. >> >>=20 >> >> [0] http://hydra.gnu.org/build/1114596 >> >> [1] https://download.qt.io/official_releases/qt/5.6/5.6.0/single/qt-e= verywhere-opensource-src-5.6.0.tar.xz >> >> [2] https://download.qt.io/official_releases/qt/5.6/5.6.0/submodules/ >> >>=20 >> > >> > Finally got around to building qtbase out, took me 6 hours total on my >> > machine. So since hydra[1] says it takes 7:15 it's a bit shorter. I >> > haven't had a chance yet to try out qmake on the other modules or to t= ry >> > to optimize the build yet. One of the things I did want to try was >> > replacing python2 with python-wrapper and enabling parallel-builds. >> > >> > I opted for straight out copying qt-5's build rather than inheriting so >> > it'll be easier to remove it if/when we're ready, and I updated the >> > license based on the text shown during build-time. >> > >> > I've attached what I have so far if anyone else wants to take a look at >> > it while I'm working on it. >>=20 >> Nice! I gather that some applications require more than just qtbase, so >> we=E2=80=99d need to have all the different Qt components before we can = fully >> switch to this model, right? >>=20 >> Now, this could be done incrementally: we could start moving packages >> that need nothing beyond qtbase to this new package, and so on. >>=20 >> Thoughts? > > That was my plan. Looking at nix's qt-5 it doesn't look like they even > build all of the packages so hopefully it shouldn't be too long. My > original hope that the base would take significantly less time didn't > pan out, but this is still good. I'm now hoping that since qtbase took > forever the other modules should be quick. Cool. >>=20 >> > Also very worthy of note, qt-5.5.1 is listed at 288 MB, and qtbase-5.6= .0 >> > is all of 85 MB. >> > >> > efraim@debian-netbook:~$ du -sch >> > /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/* >> > 6.6M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/bin >> > 560K /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/doc >> > 25M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/examp= les >> > 20M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/inclu= de >> > 30M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/lib >> > 2.5M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/mkspe= cs >> > 2.6M /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/plugi= ns >> > 85M total >>=20 >> It would be awesome if this would use the various configure flags that >> our qt4 package is using, such that we don=E2=80=99t have weird top-level >> directories such as =E2=80=99mkspecs=E2=80=99 and =E2=80=98plugins=E2=80= =99. >>=20 >> If would be worth trying to move doc/ and examples/ to a =E2=80=9Cdoc=E2= =80=9D output, >> but as noted in a comment in qt4, moving the examples may not be >> possible. >>=20 >> Could you give it a try? >>=20 > > mkspecs we actually might need, it has qmake.conf files for tons of > different architecture/OS options. Sure; I=E2=80=99m not suggesting to remove =E2=80=98mkspecs=E2=80=99, just = to move it in a more standard place, as done in qt4: "-importdir" (string-append out "/lib/qt-4" "/imports") > Examples hopefully we can split out, but reading the note for qt-4 I'm > not too optimistic. Docs don't look to me like they're big enough to > bother with. Plugins has interface .so files for things like different > sql databases and other stuff. Ludo=E2=80=99.