Re: [gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic

[Michał Górny]

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