lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Parallel-make output: deterministic for wx only?


From: Vadim Zeitlin
Subject: Re: [lmi] Parallel-make output: deterministic for wx only?
Date: Wed, 18 Apr 2018 01:15:00 +0200

On Tue, 17 Apr 2018 22:57:16 +0000 Greg Chicares <address@hidden> wrote:

GC> Comparing logs of full 'install_msw.sh' runs (the MSW script, not just
GC> the WX script that it invokes), I see something curious. For lmi, and
GC> for every library except wx, the order in which object files are
GC> compiled changes from one run to the next.

 I'm really not sure why should it be the case. I guess it's not
impossible, in principle, if compiling different files takes very different
amounts of time from run to run, but I have no idea why would it happen in
practice and, AFAIR, building lmi using autoconf toolchain does always
build the files in the same order (although I admit I haven't examined the
diffs to be sure about it).

GC> But for wx, every invocation of 'i686-w64-mingw32-g++' appears to occur
GC> in an invariant, determinate order--only for wx and its submodules.

 FWIW, wx own makefiles and submodules makefiles are quite different.

GC> Copying and pasting the 'make' command from one of these logs here:
GC> + make --jobs=32
GC> would seem to prove that a large number of jobs are run in parallel,
GC> and xfce's "CPU Graph" shows every processor maxed out for several
GC> minutes.

 Yes, I'm absolutely sure that building with parallel make does use as many
parallel jobs as specified.

GC> This is really nice. Compare two logs with 'meld', and it takes time
GC> to look at all of the rearranged chunks highlighted in color, just to
GC> be sure that (e.g.) libxml2 did indeed build correctly once again.
GC> But the wx part just matches perfectly, so a successful build is
GC> obvious, and any error would stand out clearly. What's the magic?

 I have absolutely no idea, sorry. There is no special magic in wx
makefiles, for sure, so maybe it's lmi makefiles that do something strange
that results in build order changing all the time?

GC> Pre-sort the list of object files passed to make? Intercept makefile
GC> output and sort the 'g++' commands?

 The latter certainly could be done, but it would break the link between
the compilation commands and any diagnostics emitted by them. Of course,
considering that lmi builds use -Werror, there shouldn't be any, so
checking make exit status first and then sorting the log only if it was
successful would seem to be doable.

 Regards,
VZ


reply via email to

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