guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qt: monolithic or modular?


From: Ludovic Courtès
Subject: Re: qt: monolithic or modular?
Date: Fri, 20 May 2016 13:56:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Efraim Flashner <address@hidden> skribis:

> On Thu, May 19, 2016 at 02:15:07PM +0200, Ludovic Courtès wrote:
>> Efraim Flashner <address@hidden> skribis:
>> 
>> > 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 long 
>> >> build time (7 hours on hydra [0]). Currently we download and use the big 
>> >> download of qt[1] and frankly I'd rather not. Qt does also ship in 
>> >> smaller bits[2], 32 if I counted correctly. I propose we package the 
>> >> submodules and over time we go through the packages that use qt and 
>> >> switch out the monolithic qt for just the parts that the program actually 
>> >> uses. It makes it less 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 module, not all of qt.
>> >> 
>> >> [0] http://hydra.gnu.org/build/1114596
>> >> [1] 
>> >> https://download.qt.io/official_releases/qt/5.6/5.6.0/single/qt-everywhere-opensource-src-5.6.0.tar.xz
>> >> [2] https://download.qt.io/official_releases/qt/5.6/5.6.0/submodules/
>> >> 
>> >
>> > 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 try
>> > 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.
>> 
>> Nice!  I gather that some applications require more than just qtbase, so
>> we’d need to have all the different Qt components before we can fully
>> switch to this model, right?
>> 
>> Now, this could be done incrementally: we could start moving packages
>> that need nothing beyond qtbase to this new package, and so on.
>> 
>> 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.

>> 
>> > Also very worthy of note, qt-5.5.1 is listed at 288 MB, and qtbase-5.6.0
>> > is all of 85 MB.
>> >
>> > address@hidden:~$ 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/examples
>> > 20M     /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/include
>> > 30M     /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/lib
>> > 2.5M    /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/mkspecs
>> > 2.6M    /gnu/store/r9bpiyz2w5bkavnx3s1ffxpgc51wa9z5-qtbase-5.6.0/plugins
>> > 85M total
>> 
>> It would be awesome if this would use the various configure flags that
>> our qt4 package is using, such that we don’t have weird top-level
>> directories such as ’mkspecs’ and ‘plugins’.
>> 
>> If would be worth trying to move doc/ and examples/ to a “doc” output,
>> but as noted in a comment in qt4, moving the examples may not be
>> possible.
>> 
>> Could you give it a try?
>> 
>
> mkspecs we actually might need, it has qmake.conf files for tons of
> different architecture/OS options.

Sure; I’m not suggesting to remove ‘mkspecs’, 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]