guix-devel
[Top][All Lists]
Advanced

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

Re: qt: monolithic or modular?


From: Efraim Flashner
Subject: Re: qt: monolithic or modular?
Date: Sun, 5 Jun 2016 10:24:18 +0300
User-agent: Mutt/1.6.1 (2016-04-27)

On Fri, Jun 03, 2016 at 10:30:32PM +0200, Andreas Enge wrote:
> Hi Efraim,
> 
> as you have noticed, I have created a wip-qt branch, mainly to test building
> qtbase on mips. I removed the removal of mips; but it turns out that an input
> is missing anyway. So I think we can include mips for the time being, it does
> no harm and may serve as a reminder. It also builds on arm, which is a 
> progress
> compared to our current monolithic qt. So maybe the packages that depend on qt
> will finally be available on arm again.
> 
> One thing I did not yet have time to do was to check whether all inputs were
> referenced in the result; I would have expected that the base package would
> require less inputs than the whole.
> 
> After that, I think we can push to master, as the new package is completely
> independent of the old one, and nothing can break. I think it will serve no
> purpose to keep the separate wip-qt branch, as each evaluation is quite
> costly; this one took about 3,5 hours, and I just created the branch since
> hydra was idle (which will hopefully change with the building of 
> core-updates).
> My apologies, since your patch did not apply any more, I copied and pasted
> by hand and forgot to add you as a coauthor. We can correct this on master.
> 
> What do you think?
> 
> Andreas
> 

To be fair, it was only the arm build that took 3.5 hours, i686 and
x86_64 both took about an hour. I've added to the wip-qt branch with
some of the "round 1"/direct dependencies on qtbase. I haven't had a
chance yet to try redirecting some of our qt-dependant packages on the
new system but I'm guessing it'll be soon.

As for the wip-qt branch, now with qtbase already in master I think it
makes sense to rebase the branch on master (and let me squash a commit
or two) and we can see about switching packages from qt to qtbase.

I wanted to make a nice ascii-art chart, but I'll just post the output
and reword it after:

nixpkgs/pkgs/development/libraries/qt-5/5.6$ grep qtInputs -R
qtgraphicaleffects.nix:  qtInputs = [ qtdeclarative ];
qtimageformats.nix:  qtInputs = [ qtbase ];
default.nix:      propagatedBuildInputs = args.qtInputs ++
(args.propagatedBuildInputs or []);
qtsvg.nix:  qtInputs = [ qtbase ];
qttranslations.nix:  qtInputs = [ qttools ];
qtconnectivity.nix:  qtInputs = [ qtbase qtdeclarative ];
qtwebsockets.nix:  qtInputs = [ qtbase qtdeclarative ];
qtlocation.nix:  qtInputs = [ qtbase qtmultimedia ];
qtsensors.nix:  qtInputs = [ qtbase qtdeclarative ];
qttools.nix:  qtInputs = [ qtbase qtdeclarative ];
qtdoc.nix:  qtInputs = [ qtdeclarative ];
qtdeclarative/default.nix:  qtInputs = [ qtbase qtsvg qtxmlpatterns ];
qtscript/default.nix:  qtInputs = [ qtbase qttools ];
qtenginio.nix:  qtInputs = [ qtdeclarative ];
qtserialport/default.nix:  qtInputs = [ qtbase ];
qtx11extras.nix:  qtInputs = [ qtbase ];
qtmultimedia.nix:  qtInputs = [ qtbase qtdeclarative ];
qtxmlpatterns.nix:  qtInputs = [ qtbase ];
qtquickcontrols.nix:  qtInputs = [ qtdeclarative ];

round 0:
qtbase

round 1:
qtsvg, qtimageformats, qtx11extras, qtxmlpatterns, qtserialport

round 2:
qtdeclarative

round 3:
qtgraphicaleffects, qtconnectivity, qtwebsockets, qtsensors, qttools,
qtdoc, qtenginio, qtmultimedia, qtquickcontrols

round 4:
qttranslations, qtlocation

and that gets us to about where nix has broken down the internal qt
dependencies for us.

-- 
Efraim Flashner   <address@hidden>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature


reply via email to

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