http://www.mediafire.com/file/zv4bjqs7q ... x86_64.xzm
(74 MB)
Qt 5.9.0 (framework)
Qt 5.9.0 (framework)
Last edited by fulalas on 03 Jul 2017, 01:19, edited 1 time in total.
Re: Qt 5.9.0 (framework)
arch or slackware based?
74MB is bloated (I assume MB and not Mb) don't you think?
74MB is bloated (I assume MB and not Mb) don't you think?
Re: Qt 5.9.0 (framework)
@jssouza, Qt base is indeed smaller. However this is not Qt base only, but, instead, the full Qt framework module for developers, and that's why it's not that small.
This version is Arch based, but I've just seen that AlienBob built a module a couple of days ago (he was stuck at 5.7.1), and if you look carefully you'll notice that his module has the same size as mine.
Regarding mb vs Mb vs MB, yeah, technically I'm wrong when I write mb, since the correct form seems to be MB (mega bytes). I'll fix that. Thanks
This version is Arch based, but I've just seen that AlienBob built a module a couple of days ago (he was stuck at 5.7.1), and if you look carefully you'll notice that his module has the same size as mine.
Regarding mb vs Mb vs MB, yeah, technically I'm wrong when I write mb, since the correct form seems to be MB (mega bytes). I'll fix that. Thanks
Re: Qt 5.9.0 (framework)
Well, if alien provides the same components of the framework, your module and alien's should be similar in size shouldn't it, as both an xzm module and a txz package uses the xz compression?
What I meant was, since porteus provides the module based approach and mechanism to activate and deactivate modules on the fly, why not split qt into logical modules and activate them when needed? It would also help in a rammod copy2ram scenario.
Even for a developer who just wants to create a widget based application or even to create a QML/Quick application, activating a 74MB module for it is overkill dont you think?
Even Qt provides release sources as submodules (You can see qt 5.9.1 is already released )
http://download.qt.io/official_releases ... ubmodules/
Not all applications need heavy modules like qt webkit and webengine.
- A logical split would be qt-base module (that contains qtbase, qtx11-extras and qtsvg) along with qt dependencies (libinput, libxkbcommon, xcb utils) -> This is also the needed dependecies for lxqt
- qt declarative, qt quick controls and qt graphical effects would be the qt-quick module
- qttools, qtscript and headers and .la files exported from the above modules would be the qt-devel module
- Qt Creator built from these modules
I had such a split when I was developing a qt quick application during qt 5.6 days. The module sizes were: qtbase.xzm -> 8.8 MB, qtdevel.xzm -> 12MB, qtquick -> 4MB and qtcreator 16MB. I could also activate a subset of these modules to run the lxqt 0.10 desktop or develop and run widget only applications.
Additional modules could be added as needed (Also, if you remove unneeded libraries from lxqt, they could go into a qt-extra module).
What do you think?
What I meant was, since porteus provides the module based approach and mechanism to activate and deactivate modules on the fly, why not split qt into logical modules and activate them when needed? It would also help in a rammod copy2ram scenario.
Even for a developer who just wants to create a widget based application or even to create a QML/Quick application, activating a 74MB module for it is overkill dont you think?
Even Qt provides release sources as submodules (You can see qt 5.9.1 is already released )
http://download.qt.io/official_releases ... ubmodules/
Not all applications need heavy modules like qt webkit and webengine.
- A logical split would be qt-base module (that contains qtbase, qtx11-extras and qtsvg) along with qt dependencies (libinput, libxkbcommon, xcb utils) -> This is also the needed dependecies for lxqt
- qt declarative, qt quick controls and qt graphical effects would be the qt-quick module
- qttools, qtscript and headers and .la files exported from the above modules would be the qt-devel module
- Qt Creator built from these modules
I had such a split when I was developing a qt quick application during qt 5.6 days. The module sizes were: qtbase.xzm -> 8.8 MB, qtdevel.xzm -> 12MB, qtquick -> 4MB and qtcreator 16MB. I could also activate a subset of these modules to run the lxqt 0.10 desktop or develop and run widget only applications.
Additional modules could be added as needed (Also, if you remove unneeded libraries from lxqt, they could go into a qt-extra module).
What do you think?
Re: Qt 5.9.0 (framework)
@jssouza, you're totally right. Although a module that uncompressed uses just 275 MB of RAM is not that much, you have a point. Since I made this module for developers, Porteus community lacks a Qt-base only module, which would fit most regular users (opposed to developers).
Unfortunately I don't have time to split it in many modules the way you're asking for, but it would be great if you could do that for us.
P.S.: I'm aware of 5.9.1 release. I'm just waiting Arch to finish testing it. And maybe Alien will release an update module soon.
Unfortunately I don't have time to split it in many modules the way you're asking for, but it would be great if you could do that for us.
P.S.: I'm aware of 5.9.1 release. I'm just waiting Arch to finish testing it. And maybe Alien will release an update module soon.
Re: Qt 5.9.0 (framework)
I think you misunderstood. I meant build our own qt 5.9.1 framework from sources. Not be dependent on Arch, and then start splitting the modules.
From what I know, Arch has a different way of installing the qt libraries than slackware.
From what I know, Arch has a different way of installing the qt libraries than slackware.
Re: Qt 5.9.0 (framework)
I don't know about Qt 5.9.0, but older versions were a pain in the ass to compile from scratch. That's probably why until few days ago AlienBob was stuck with 5.7.1 (which is 1 year old). Have you seen the amount of patches needed to compile Qt for Slackware? It's insane!jssouza wrote:I think you misunderstood. I meant build our own qt 5.9.1 framework from sources. Not be dependent on Arch, and then start splitting the modules.
Anyway, as I told you: feel free to create the modules for us!