On pon, 2017-03-20 at 21:12 -0400, Mike Frysinger wrote: > On 20 Mar 2017 20:35, Michał Górny wrote: > > Remove the parallel econf logic that adds a lot of complexity for minor > > gain. It results in the output from different configure scripts being > > mixed in the build log, making it unreadable. It causes econf to be run > > in a subshell which is a PMS violation and can cause issues with some of > > package manager implementations. Furthermore, the multijob parallel > > processes are interleaved with multilib-build logic which is unsupported > > and a very bad idea. > > NAK. you still haven't backed up your claims wrt to PMS, and this slows > things down significantly.
You have found the appropriate PMS bit yourself, and chose to ignore it. What can I do about that? How am I going to convince you that '*not* guaranteed to work correctly if called from a subshell environment' means you're not supposed to do that? If I submit a PMS patch changing the wording to state the obvious you're going to accuse me once again of changing PMS wording to target you. Furthermore, I have linked an *explicit Portage bug* causing breakage with your code. However, you've presumed that it's fine as long as it will soon be fixed in the git version of Portage. Finally, I should point out that PMS was *not* written with parallel execution in mind. It was not deemed useful. It states no requirements on parallel run guarantees, and so you can't expect package managers to implement those commands in parallel-friendly way. It's bigger than you. How about we turn things around, and start expecting maintainers to justify their non-standard solutions instead? Please tell me, do you think every other Gentoo developer is wrong not to do parallel econf? Do you think I was stupid that I've removed that can of worms out of multibuild? Could you back your 'significant slow down' claim with any data? Here's my results, MAKEOPTS=-j3 USE='cxx debug threads tinfo unicode' ABI_X86='32 64', warm cache. The whole build takes around 25 minutes, the configure phase (as measures by 'ebuild ... prepare; time ebuild ... configure': parallel: 2m35s serial: 3m47s We can dispute whether 1 minute gain out of 25 is meaningful. But instead, I'd like to propose a better solution -- to use --cache-file= to avoid redoing the same checks in subsequent runs. cached: 2m24s ...which proves it's faster than the parallel solution, and has the major advantage of saving both CPU and wall clock time. Any reason not do that? A patch will follow. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
