paste.md

While working on this, I had a thought: wouldn't it be consistent to also allow executable components depend on some package which depends on the library? I think supporting cabal stanzas in a uniform way will help clarify the code.

So far, I'm having some trouble with refactoring the code to add this feature in a nice way. I think a large-ish restructure is in order, both to clarify things and to enable this change. The main thing I'd like to change is to improve how the build steps are represented, and clarify which components will be built.

First off, here are some notes about how things currently work:

• The Package type sets testEnabled / benchEnabled based on whether these are part of the configuration - here. The purpose of this seems to be to affect the results of allBuildInfo', and so affect the results of querying the package's dependencies (packageDependencies, packageToolDependencies, packageDescTools). So, this also affects the population of the packageDeps field.

• loadLocalPackages is where things get tricky. Here's what happens:

  • We write down a Just value for the lpExeComponents if the package is a build target. I think this applies even if there isn't an exe component, and it's just a library. lpExeComponents is used in the following ways:

    • If it or lpTestBench is set, then it's a wanted package

    • If it's set, then constructPlan will plan to build it as a normal task

    • The components get provided to cabal build during execution, here. The Nothing case is confusing to me, I'm not sure which circumstances it happens.

  • lpTestDeps is set to the dependencies of the tests, similarly for lpBenchDeps. This is used to determine whether we should enable tests even when not building them, to avoid reconfigure (and probably avoid writing cabal_macros.h again)

  • lpTestBench is set to a package which is configured with all, but it is only a Just if there are any tests or benchmarks that are targets. It is a LocalPackageTB, which stores a Package along with the set of tests and benchmarks that are targets.

In all, this feels like a lot of in flight, and a lot to understand while reading the code for package execution. How about restructuring things like this:

• Don't have singleBuild / singleTest execute build actions. Instead, each element of planTasks specifies that a particular set of package components to be built. A package will either be built all in one Task or be split into two: one for the Lib, and one for the rest of the components.

• Have the final actions just store enough info to run the test or benchmark.

• Possibly turn the fields of Package / LocalPackage which depend on the targets into functions which take the type along with the targets? To me it's hard to tell what's going on when a Package / LocalPackage / LocalPackageTB implicitly has been configured with some set of targets.