GitLab

So the DistDirLayout now contains the root dir of the project as a
whole, which eliminates the need to pass it separately in several cases.
It also contains the location of the cabal.project file, which again
avoids having to pass it around.

In part these changes were to allow the elimination of uses of the
legacy config types in the new-build code. The idea is that the legacy
config types are only used by conversion into the new config types, and
then only the new types are used in the new code.

The stuff about the new-build/nix-local-build beta

Due to a change in behaviour: giving no target no longer means build
everything, instead there is an explicit 'all' target.

This means we can say things like:
cabal build tests     -- for the tests in the package in the cwd
cabal build foo:tests -- for the tests in package foo
cabal build all:benchmarks -- benchmarks in all packages in the project

The target selector matching now only returns packages that are local to
the project. This means that when resolving packages later, if a lookup
for the details of a package fails, then it's an internal error whereas
previously it just meant it was a package outside of the project.

Do it by constructing special output rather than constructing special
input. It's a bit clearer and more robust to refactoring this way.

Talk about cwd / current dir package rather than primary package.

The command line target syntax has two main use cases: humans who prefer
short forms and can deal with occasional ambiguity, and programs/scripts
which need unambiguous syntax but it's ok if it's a big long.

This patch changes the syntax for the long unambiguous form. It makes
sure we have a fully qualified form for each target kind, and makes them
consistent with each other. This is the syntax that will need to be
documented for script authors (possibly in the --help in addition to the
user guide).

Make our policy be to use ambiguity by default, and then use shadowing
where that really makes sense.

In practice that means the 2, 3 and 4-component forms are part of the
top level ambiguousAlternatives list, rather than nested within groups
using shadowingAlternatives.

For the fully qualified forms this makes no difference since they are
not ambigious with each other. For the 2 & 3-component forms, in rare
cases they can be ambigious with each other and so we'll now report
that ambiguity rather than hiding it with explicit shadowing.

Also add comments to this effect.

Extend TargetSelector with a TargetAllPackages constructor with the
corresponding concrete command line syntax 'all'. The interpretation of
this is extended for all commands to be the same as if the list of all
packages local to the project were given.

Since the concrete syntax for the meta-target 'all' can in principle
clash with a package 'all' or a component 'all', this short form of
syntax is made to be ambigious with the existing short forms for
packages or components, and new more qualified forms are added.

This means that a user writing 'cabal build all' in a project where
there is a local package 'all' or a component 'all' in the package in
the cwd (but not any package 'all' as a dependency or any component
'all' in any package other than the one in the cwd), will be informed
that the syntax is ambigious and will be told the more qualified forms
of the possible targets. These would be ':all' and 'pkg:all'. The use of
the usual ':' separator with an empty string is the explicit indicator
of a meta namespace. Since 'pkg:all' itself is also potentially
ambigious with a package named 'pkg' containing a component 'all' then
there is a further qualified form ':pkg:all' to select the package named
'all'.

This more qualified syntax need only be used in these highly unusual
ambigious cases and the user will be informed. The intention, as has
been the case previously, is to allow a normal syntax that is short and
convenient but potentially ambigious in rare cases, while still allowing
all cases to be expressed unambigiously.

It was being used in one error message, in a place that will shortly be
replaced, and it would not make sense with upcomming changes to the
TargetSelector representation. So it's better to remove it now and fix
the place where it was being used later.

Demote TargetString document TargetSelector. Reorder TargetString
section. Rename use of userTarget naming convention to match new type
names.

Drop use of term "build" from error messages since these errors will
appear for many commands, not just the build command.

Rename UserBuildTarget to TargetString, to match the previous renaming
of BuildTarget to TargetSelector. Also rename the corresponding
functions.

So there's now just one error type rather than two, and errors are
returned rather than reported directly.

Now that we have squashed together the two phases of the target
selector parsing and resolving, we also want to do the same with the
error reporting for the two phases. And to make it possible to customise
the error messages for different commands we have the reporting being
done explicitly and separately.

This means that in the majority of cases we can report errors in the
command line arguments prior to running the solver. This is a much
better state of affairs. Previously we had to wait many seconds (or
sometime more) before being able to report problems. Worse, with the
previous scheme the solver may fail to find a solution and so we'd
end up reporting that rather than the problem with the user's target.

Reduce it from info to debug and put it in a more sensible place where
we can also report if it's parallel or serial more easily.

This is part of the refactoring to resolve command line build targets
without first having to run the solver and produce the elaborated
install plan.

Previously runProjectPreBuildPhase would do all the early steps
including finding the project root and establishing the project
config and the local packages. This patch splits those early steps
out into a separate pass in the project orchestration. It also
eliminates the need for the hookPrePlanning and since there's then
only one hook left we don't bother to name the PreBuildHooks.

Having split getting the project config from constructing the install
plan we can simplify how the project config is handled. This lets us
pass just one set of ProjectConfig to resolveBuildTimeSettings rather
than parts of both the persistent and the cli ProjectConfig.

Previously we had a rebuildInstallPlan that does everything up to
producing the elaborated install plan. This included reading the project
config and all the local package description files etc.

It is useful to split this latter aspect out separately. The reason for
this is that we would really prefer to resolve command line build
targets without first having to run the solver and produce the
elaborated install plan. We would prefer to be able to report mistakes
in the build targets more or less instantly rather than having to wait
many seconds (or sometime more) before being able to report problems.
Worse, with the current scheme the solver may fail to find a solution
and so we'll end up reporting that rather than the problem with the
user's build target. Indeed problems with a build target are most likely
to happen when the project config is messed up (or not what users
expect, or before they understand the model) and those are the cases
where it's most likely that there is no project solution.

So this is a step towards being able to do all target resolution prior
to solving.

Also make the qualifiers case insensitive

It is not actually canonical for directories with vs without a trailing
slash. This bug is present in newer directory releases, older versions
work correctly.

Filed as https://github.com/haskell/directory/issues/63

Comments, error messages and updated example inputs.

So instead of a big set of matcher functions and and one big render
funtion, we split it up so that each form of syntax is a thing on its
own with both the matcher and renderer for that form. Then we collect up
all the various syntax forms.

This makes the pairing much easier, and much clearer when we add new
forms of syntax.

Handy for debugging and testing

Add shortcut behaviour to matchPlusShadowing. This does not change the
semantics, just avoids computing unnecessary matches.

We're going to generalise it and the name will no longer be appropriate.
We'll add the ability to select all packages, or to select only certain
kinds of components in a package. So this makes it less like a resolved
target and more or an expression that needs further work to resolve to
a set of targets.

We already have the SubComponentTarget type so we can use this to better
factor the BuildTarget type, and simplify conversions.

The way it is currently implemented is incompatible with the new target
checking code, since it really selects everything, including things that
are not buildable. This leads directly to failre when we check that the
things the user has asked to build are in fact buildable.

So far they just build the exe bench and don't do the next steps,
but they do at least select the right components to build.

Also bring the existing test command into sync with the others.

Rather than having it appear in the [other] section. I've just guessed
at where it ought to go. Suggestions welcome.

This is slightly tricky stuff to write since it has to be concise,
clear, accurate and make sense without too much context. This and
the examples should be reviewed with comparison to the user guide.

It looks like CmdHaddock was based on the CmdConfigure template and so
copied some bits that don't make sense for it. Change those bits to be
the same as for build.

In particular for printing the plan, the configure command always
behaves as if it is in --dry-run mode, but that's not appropriate for
the haddock command. The other change is to follow the standard pattern
for the runProjectBuildPhase / runProjectPostBuildPhase and the handling
of the --dry-run option, which is handled internally by those and does
not need to be handled explicitly in CmdHaddock.

And also reject --only-dependencies for the haddock command.