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/Configure.hs

@@ -299,6 +299,7 @@ configureSetupScript
       , useDependenciesExclusive = not defaultSetupDeps && isJust explicitSetupDeps
       , useVersionMacros = not defaultSetupDeps && isJust explicitSetupDeps
       , isInteractive = False
+      , isMainLibOrExeComponent = True
       }
     where
       -- When we are compiling a legacy setup script without an explicit

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

@@ -1717,14 +1717,18 @@ elaborateInstallPlan
               -- invocation of the same `./configure` script.
               -- See https://github.com/haskell/cabal/issues/4548
               --
-              -- Moreover, at this point in time, only non-Custom setup scripts
-              -- are supported.  Implementing per-component builds with
-              -- Custom would require us to create a new 'ElabSetup'
+              -- 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
-                  PD.Configure -> [CuzBuildType CuzConfigureBuildType]
+                  PD.Configure -> []
+                  -- Configure is supported, but we only support configuring the
+                  -- main library in cabal. Other components will need to depend
+                  -- on the main library for configured data.
                   PD.Custom -> [CuzBuildType CuzCustomBuildType]
                   PD.Hooks -> [CuzBuildType CuzHooksBuildType]
                   PD.Make -> [CuzBuildType CuzMakeBuildType]
@@ -3878,6 +3882,16 @@ setupHsScriptOptions
       , forceExternalSetupMethod = isParallelBuild
       , setupCacheLock = Just cacheLock
       , isInteractive = False
+      , isMainLibOrExeComponent = case elabPkgOrComp of
+          -- if it's a package, it's all together, so we have to assume it's
+          -- at least a library or executable.
+          ElabPackage _ -> True
+          -- if it's a component, we have to check if it's a Main Library or Executable
+          -- as opposed to SubLib, FLib, Test, Bench, or Setup component.
+          ElabComponent (ElaboratedComponent{compSolverName = CD.ComponentLib}) -> True
+          ElabComponent (ElaboratedComponent{compSolverName = CD.ComponentExe _}) -> True
+          -- everything else is not a main lib or exe component
+          ElabComponent _ -> False
       }
 
 -- | To be used for the input for elaborateInstallPlan.

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

@@ -315,6 +315,12 @@ data SetupScriptOptions = SetupScriptOptions
   -- ^ Is the task we are going to run an interactive foreground task,
   -- or an non-interactive background task? Based on this flag we
   -- decide whether or not to delegate ctrl+c to the spawned task
+  , isMainLibOrExeComponent :: Bool
+  -- ^ Let the setup script logic know if it is being run to build a main
+  -- library or executable component.  This is used to determine if we should
+  -- use the configure command, if the build-type is 'Configure'.  For
+  -- configure, only the main library and execomponents have 'configure'
+  -- support, and thus we can skip running configure for other components.
   }
 
 defaultSetupScriptOptions :: SetupScriptOptions
@@ -339,6 +345,7 @@ defaultSetupScriptOptions =
     , forceExternalSetupMethod = False
     , setupCacheLock = Nothing
     , isInteractive = False
+    , isMainLibOrExeComponent = True
     }
 
 workingDir :: SetupScriptOptions -> FilePath
@@ -375,7 +382,14 @@ getSetup verbosity options mpkg = do
                 (useCabalVersion options)
                 (orLaterVersion (mkVersion (cabalSpecMinimumLibraryVersion (specVersion pkg))))
           }
-      buildType' = buildType pkg
+      -- We retain Configure only for the main library and executable components.
+      -- For other components, we rewrite the buildType to Simple to skip the
+      -- configure step.  This is because the configure step is not supported for
+      -- other components.  Configure can only impact MainLib and Exe through
+      -- .buildinfo files.
+      buildType' = case (buildType pkg, isMainLibOrExeComponent options) of
+        (Configure, False) -> Simple
+        (bt, _) -> bt
   (version, method, options'') <-
     getSetupMethod verbosity options' pkg buildType'
   return

cabal-testsuite/PackageTests/Configure/cabal.out

@@ -4,8 +4,8 @@ Configuration is affected by the following files:
 Resolving dependencies...
 Build profile: -w ghc-<GHCVER> -O1
 In order, the following will be built:
- - zlib-1.1 (lib:zlib) (first run)
-Configuring zlib-1.1...
+- zlib-1.1 (lib) (first run)
+Configuring library for zlib-1.1...
 Warning: Flags 'con_flict', 'con-flict' all map to the same environment variable 'CABAL_FLAG_con_flict' causing a collision. The value first flag 'con_flict' will be used.
 Preprocessing library for zlib-1.1...
 Building library for zlib-1.1...

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.
+
+}