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: Thu, 19 May 2016 14:15:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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?

> 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?

Thanks,
Ludo’.



reply via email to

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