[Releasing] Testing and verification of Alpha package

[marius.storm-olsen at nokia.com]

Mingw32-make actually supports the -j<n> option, but requires sh.exe to be present.

Jom does a great job though, no need to switch :-)

--
Sent from my Nokia N9On 3/19/12 19:07 ext shane.kearns at accenture.com wrote:
> -----Original Message-----
> From: Rohan McGovern [mailto:rohan.mcgovern at nokia.com]
> Sent: 18 March 2012 23:29
> To: Kearns, Shane
> Cc: releasing
> Subject: Re: [Releasing] Testing and verification of Alpha package
>
> shane.kearns at accenture.com said:
> > Windows 7 MSVC2010 x64 build issues:
> >
> > "configure -opensource -confirm-license"
> >
> > Jom (current jom-stable downloaded today) cannot parallelise the
> build properly. Every test is built strictly sequentially, therefore
> only one core is in use for most of the build time.
>
> If I understand correctly, jom does not do true recursive parallelism
> as
> GNU make does[1]; I think it would parallelize within a subdir, but
> would
> not build multiple subdirs concurrently.  I hope to be corrected if I'm
> wrong.

Mingw32-make doesn't support that, which was my original reason for switching to msvc + jom for windows builds.
On Qt4 with jom 0.8.8, jom gave the impression of 100% CPU usage through most of the build (I'll need to try that old version again)

However, my normal usage was to build src/ first (configure, cd src, qmake, jom)
And build tests/auto/ only when there was something to test.

> This means it indeed gives quite poor performance when building
> hundreds
> of projects with 1-2 source files each ... like unit tests :(

This should be able to create 16 jom instances each building a different test.
With the flat hierarchy of Qt 4, running jom from tests/auto would have worked like this if it's not recursively parallel
And with Qt 5 I wouldn't have noticed so far, due to building either tests/auto/corelib or tests/auto/network depending what I'm testing (or "nmake check" which is expected to be slow and non parallel)

But if there's one make or jom instance building all of tests/ it will be expected to take a long time.

Proper parallelism requires a non recursive makefile.
(Though you pay a higher cost at the makefile generation step)

> >
> > -          Repeatable when running again on the failed build
> > Jom has no console output during the build, it is all dumped at the
> end when the build failed. (output stopped when configuring multimedia,
> at end of build the scrollback buffer was full)
> >
>
> Was that jom 1.0.11 ?  Several jom versions had output buffering issues
> and this is one reason why jom was not upgraded in Qt Project CI for a
> long time.  But these problems seemed to have been fixed by now in my
> testing.

Yes, 1.0.11

> You can file jom bugs against QTCREATORBUG and they seem to have a good
> chance of being looked at.
>
> [1] incidentally, http://mad-scientist.net/make/jobserver.html is an
> interesting read about GNU make -j .

That implementation using unix signals probably explains why it's not in mingw32-make.

________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com

Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing