configure phases of build-type:configure replicated for multiple components for local builds

[hvr]

Simple way to reproduce this:

$ cabal get network-2.6.3.2 && cd network-2.6.3.2/
$ cabal new-build --enable-tests -j4 all
Resolving dependencies...
In order, the following will be built (use -v for more details):
 - network-2.6.3.2 {network-2.6.3.2-inplace} (lib) (first run)
 - network-2.6.3.2 {network-2.6.3.2-inplace-doctest} (test:doctest) (first run)
 - network-2.6.3.2 {network-2.6.3.2-inplace-simple} (test:simple) (first run)
 - network-2.6.3.2 {network-2.6.3.2-inplace-regression} (test:regression) (first run)
Configuring library for network-2.6.3.2..
Configuring test suite 'doctest' for network-2.6.3.2..
configure: WARNING: unrecognized options: --with-compiler
configure: WARNING: unrecognized options: --with-compiler
checking build system type... checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... no
configure: error: in `/tmp/network-2.6.3.2':
configure: error: C compiler cannot create executables
See `config.log' for more details
no
sed: can't read conftest.c: No such file or directory
configure: error: in `/tmp/network-2.6.3.2':
configure: error: C compiler cannot create executables
See `config.log' for more details
cabal: Failed to build network-2.6.3.2 (which is required by test:simple from
network-2.6.3.2 and test:regression from network-2.6.3.2). The failure
occurred during the configure step. The build process terminated with exit
code 77
Failed to build test:doctest from network-2.6.3.2. The failure occurred during
the configure step. The build process terminated with exit code 77

Notice how configure is invoked simultaneously for the lib and test:doctest component, finally resulting in two configure-runs corrupting each other.

This would be fine for non-local per-component builds, but local builds of local per-components share a common work-folder where configure operates, so this is redundant work (as all configure invocations are supposed to have the same result -- NB: .buildinfo files are often generated by those which the subsequent build-process depends upon!) and more importantly causes actual failures.

/cc @ezyang

[ezyang]

A few points;

• Yes, this is absolutely a problem, and it's not obvious how to fix it.
• If you can arrange for configure to run to completion before building other components in parallel (not the case here because doctest doesn't have a dep on the main package), then configure-options: -C in the package stanza for this package helps reduce duplication

[hvr]

@ezyang I see... so the problem is that each component has slightly different invocations of ./configure; specifically the --libdirargument varies for each component... how hard would it be to just disable per-component parallelism for locally built build-type:configure packages?

[matclab]

Is there any known workaround for this problem ?

[ezyang]

@matclab

Untested patch:

diff --git a/cabal-install/Distribution/Client/ProjectPlanning.hs b/cabal-install/Distribution/Client/ProjectPlanning.hs
index 8e7020bcd..e0dee6317 100644
--- a/cabal-install/Distribution/Client/ProjectPlanning.hs
+++ b/cabal-install/Distribution/Client/ProjectPlanning.hs
@@ -1226,6 +1226,7 @@ elaborateInstallPlan verbosity platform compiler compilerprogdb pkgConfigDB
             cuz_custom =
                 case PD.buildType (elabPkgDescription elab0) of
                     PD.Custom -> cuz "build-type is Custom"
+                    PD.Configure -> cuz "build-type is Configure"
                     _         -> []
             -- cabal-format versions prior to 1.8 have different build-depends semantics
             -- for now it's easier to just fallback to legacy-mode when specVersion < 1.8

[hvr]

I've removed the priority:high again, since we should have good-enough-for-now workaround in #5002 (but I'm not giving up hope on of restoring per-compat for configure-type builds yet);
I've added a needs-backport label though, since this should be backported to the 2.0 branch in case we ever make a point-release of cabal-install-2.0

[phadej]

I removing the attention: needs-backport label.

[ulysses4ever]

I can't reproduce this anymore. I guess #5002 did fix it, even if not in the most ergonomic way. Should we close it?

[Mikolaj]

Let's close optimistically. Thank you all!