Gerrit Contributions

VRonin

Just an idea to facilitate one-off code submission.
I could prepare a Virtual Box image with a system with all the plumbing in place to contribute to Qt including a small gui to facilitate non pre-configurable actions (like setting up username and password). This should cut down dramatically the time from idea to code.
Thoughts? If you think it's a bad idea say it, I won't be offended

aha_1980

@VRonin

That actually sounds great! A Linux system should be save from license side.

And if the Qt is already configured and build, you'll save the compile time too :)

VRonin

I was thinking just a straightforward debian build.
Anyone has a full post-compile qt5.git repo? I just want to know how big the whole package would be.

aha_1980

@VRonin

I just tried to do a full build, but my system stopped "out of memory" in Qt3D.

Disk used so far: 23 GB.

I didn't even include the QtWeb* modules, see below.

perl init-repository --module-subset=default,-qtwebkit,-qtwebkit-examples,-qtwebengine
./configure -developer-build -opensource -nomake examples -nomake tests -confirm-license

Maybe I can get it to fully build tomorrow.

mrjj

@VRonin
That would an epic good idea.
We use this method exclusive at work and sit a huge timer saver.

SGaist

What about having it pre-configured and people can start compiling it after they did the modifications they want ?

Another possibility could be to provide a docker container ?

kshegunov

Will preconfiguring work, as configure does compile qmake?

SGaist

Good point, what could be done is to pre-configure Qt, clean everything and just keep the configuration files needed to re-trigger Qt's build.

kshegunov

@aha_1980
What about building only qtbase or the essential set of modules? That should be more manageable, even if somewhat constraining?
Something like the following configuration:

$> perl init-repository --module-subset=essential
$> ./configure -developer-build -opensource -nomake examples -nomake tests -confirm-license
$> make module-qtbase
$> make module-qtquickcontrols2
$> ...

@SGaist

Good point, what could be done is to pre-configure Qt, clean everything and just keep the configuration files needed to re-trigger Qt's build.

Ehm, you do need qmake to retrigger the build, or did you mean something else? My concern is with the qmake's paths that are compiled into the binary, maybe patching them would do the trick?

SGaist

config.status and config.opt are all that are needed.

kshegunov

Needed for? Triggering configure?

SGaist

Re-trigger configure using the set of parameter you original passed. In the absolute, config.opt is enough as config.status just calls configure with the -redo option.

aha_1980

Full build finished with make -j 1 ;)

Following sizes include the .git repos, the sources and the developer (debug) build artefacts, as said exluding QtWeb*:

961M	./qtxmlpatterns
9,0M	./qtspeech
58M	./qtgraphicaleffects
5,2M	./config.tests
2,1M	./coin
4,0K	./qtquick1
266M	./qtsensors
4,0K	./qtdocgallery
168M	./qtnetworkauth
1,5M	./qtmacextras
4,0K	./qtfeedback
496M	./qtdatavis3d
80M	./qtremoteobjects
18M	./qtgamepad
1,9G	./qttools
41M	./qtimageformats
149M	./qtvirtualkeyboard
1,6M	./qtandroidextras
116M	./qtqa
488M	./qtcharts
201M	./qtwebview
859M	./qtquickcontrols2
51M	./qtdoc
3,3G	./qt3d
4,0K	./qtwebengine
2,3G	./qtdeclarative
5,9M	./.git
1,4M	./qtrepotools
12M	./qtserialport
27M	./qttranslations
1,8G	./qtlocation
659M	./qtscript
174M	./qtwebsockets
160M	./qtquickcontrols
13M	./qtwayland
904M	./qtmultimedia
7,9G	./qtbase
70M	./qtscxml
202M	./qtserialbus
4,7M	./qtwinextras
4,7M	./gnuwin32
441M	./qtconnectivity
125M	./qtcanvas3d
21M	./qtwebglplugin
162M	./qtwebchannel
151M	./qtpurchasing
254M	./qtsvg
3,8M	./qtx11extras
4,0K	./qtpim
4,0K	./qtenginio
4,4M	./qtactiveqt
4,0K	./qtsystems
25G	.

VRonin

@aha_1980 Thanks!

@SGaist and @kshegunov My idea was to pre-configure and even make. That's really the time saving part. The rest can literally be included in a bash file, it's not really that taxing.

@SGaist said in Gerrit Contributions:

provide a docker container

That's actually another great idea

aha_1980

As someone that has not used Docker before: it is not as cross-platform as VirtualBox, i.e. you can use a Linux docker only in a Linux environment, not Windows, right?

mrjj

Hi
Dockers can be used in windows too but no gui possible as far as i know.
So VM would be so much more flexible and cross platform.
also dockers requires user to learn how to use them ( new commands, integration etc)
where as WM is still just a normal linux.

VRonin

Ok, so:

VM over docker

Open issues

"pre-config & make" or "pre-config and delete unnecessary stuff"
where would it be appropriate to host such a big file?
how often should it be updated and what would be the best way to do it?

aha_1980

@VRonin said in Gerrit Contributions:

where would it be appropriate to host such a big file?

Don't forget the traffic that is generated when downloading...

For me and my limited networks speed, even downloading such a big file takes several hours.

how often should it be updated and what would be the best way to do it?

Another good one :) For now, I'd set it to the tip of qt5 5.11 branch, so you could do fixes easily and even push something to dev/5.12 with good chance it can be cherry-picked without conflict.

That would mean you'd have to renew it in approx. half a year, when 5.12 is out (Given that the average user downloads no beta releases anyway).

mrjj

Hi
regarding hosting.
How big is image ?

aha_1980

@mrjj Expect something between 20 and 40 GB (depending if we keep the compile artefacts or not).