This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 27 Feb, 2017 40 commits
-
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
The stuff about the new-build/nix-local-build beta
-
Duncan Coutts authored
Due to a change in behaviour: giving no target no longer means build everything, instead there is an explicit 'all' target.
-
Duncan Coutts authored
-
Duncan Coutts authored
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
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
Do it by constructing special output rather than constructing special input. It's a bit clearer and more robust to refactoring this way.
-
Duncan Coutts authored
Talk about cwd / current dir package rather than primary package.
-
Duncan Coutts authored
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).
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
Rename UserBuildTarget to TargetString, to match the previous renaming of BuildTarget to TargetSelector. Also rename the corresponding functions.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
Also make the qualifiers case insensitive
-
Duncan Coutts authored
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
-
Duncan Coutts authored
Comments, error messages and updated example inputs.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
Handy for debugging and testing
-
Duncan Coutts authored
-
Duncan Coutts authored
Add shortcut behaviour to matchPlusShadowing. This does not change the semantics, just avoids computing unnecessary matches.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
We already have the SubComponentTarget type so we can use this to better factor the BuildTarget type, and simplify conversions.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
Rather than having it appear in the [other] section. I've just guessed at where it ought to go. Suggestions welcome.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
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.
-
Duncan Coutts authored
-
Duncan Coutts authored
And also reject --only-dependencies for the haddock command.
-