feat: allow build-type Configure to work with Components

When components were introduced, cabal had support for
build-type: Configure, which allows to run a `configure`
script prior to building the package.  Upon the introduction
of components, it became obvious that we can't just
configure each and every component, as this easily runs
into the situation where the `configure` script is run
potentially concurrently for all components.

However, build-type is a global option for cabal files, and
is usually used to produce a <pkg>.buildinfo file.  This file
is then used to augment the Main Library and Executables only.

This change now tracks whether or not we are building a
main library or executable component, and if we do, retains
only for these components the build-type: Configure from the
package description. For all other components, we will fall
back to the default build-type: Simple.  For end users who
want to depend on package configured values, they will need
to set their sub libraries, testsuites and benchmark
components to depend on the main library, and import any
configured values from there.

For lib:Cabal, which doesn't know about components
when configure is invoked, we will continue to execute
configure.  There is no impact on lib:Cabal in this change.

Author: angerman

cabal-install/src/Distribution/Client/ProjectPlanning.hs

@@ -1729,10 +1729,11 @@ elaborateInstallPlan
           why_not_per_component g =
             cuz_buildtype ++ cuz_spec ++ cuz_length ++ cuz_flag
             where
-              -- Custom and Hooks are not implemented. Implementing
-              -- per-component builds with Custom would require us to create a
-              -- new 'ElabSetup' type, and teach all of the code paths how to
-              -- handle it.
+              -- We have to disable per-component at this point in time, only
+              -- Simple and Configure build types are supported.  Custom and
+              -- Hooks are not implemented.  Implementing per-component builds
+              -- with Custom would require us to create a new 'ElabSetup'
+              -- type, and teach all of the code paths how to handle it.
               -- Once you've implemented this, swap it for the code below.
               cuz_buildtype =
                 case bt of

changelog.d/pr-10966.md

@@ -0,0 +1,20 @@
+synopsis: Allow build-type: Configure
+packages: cabal-install
+prs: #10966
+issues: #4548
+significance: significant
+
+description: {
+
+  This change allows the `build-type: Configure` field to be used in
+  Cabal packages in conjunction with components. (E.g. public sublibraries).
+  This is a significant change as it enables the use of the `Configure` build
+  type, which cabal bailed on previously.
+
+  This does change the behaviour of cabal-install for packages that contain
+  `build-type: Configure`. We now always build them as components with
+  cabal-install.  Previously we would turn packages with main libraries, and
+  executables/benchmarks/tests-suites into a single package to be built in a
+  compatibility mode.  This is no longer the case.
+
+}