GitLab

So we get more accurate helpful error messages in those cases.
Also update a corresponding test.

This is for the "packages: blah/*/" locations in cabal.project files,
when they don't match anything or match crazy unrecognised stuff.
Previously we just used the derived Show.

This implements the flag `--allow-older` which is the analogous to
`--allow-newer` acting on lower bounds.

This also adds a not yet used `AllowOlder` newtype

This is a preparatory refactoring propsed in #3466 for supporting `--allow-older`

Code to write it and to pick it up by default when reading the
cabal.project file.

For both install and new-build.

When executing the install plan, the various failures are supposed to be
caught and put into the residual install plan. This adds the main cases
for that, including the configure and build cases. Download is still not
covered.

This is a step towards better reporting of what failed when there are
failures in deps etc.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Keep the paths relative when the user specifies them as relative.
This is more consitent for file monitoring and error reporting.
Convert to absolute later (as expected by other code).

Fixes #3323 and #3324, ensuring we monitor the project Cabal files.
Original fix by Edward Z. Yang. The approach in this patch is to fix an
underlying problem. Subsequent patches use a more consistent approach to
the monitoring as suggested by Edward.

The motivating example is:

  matches <- matchFileGlob dirname glob

where matchFileGlob is defined in the RebuildMonad module as

matchFileGlob root glob = do
    monitorFiles [monitorFileGlob glob]
    liftIO $ Glob.matchFileGlob root glob

This usage is wrong because the root used to match the glob is not the
same as the root that will be used later when checking the file monitor
for changes. You can see this is suspicious because the declaration of
the monitor does not take an root dir paramater but the immediate
matching does. That's because the root for the monitors is specified
when we do the rerunIfChanged to check the monitor.

So the only correct usage involves passing in the correct root. This is
a ripe source of bugs. So this refactoring moves the root into the
Rebuild monad directly, so the example becomes:

  matches <- matchFileGlob glob

The root is implicit, so you can't accidentally pick a different root
for the immediate match vs the later monitor check. Of course the root
still matters, but if you get that wrong you'll notice immediately
because you will not get the match results you were expecting.

So the root is now passed in with runRebuild, not with rerunIfChanged.

Also change the incorrect use of matchFileGlob. This use case now
relies on the adjusted representation of glob roots, using
FilePath.splitDrive to obtain the root (if any).

There was a comment claiming that it was done already but this function
does not exist. I think it was referring to findProjectPackages, but
this function tests only matchFileGlob (so it will notice if a.cabal is
renamed to b.cabal) and not the actual contents of the file.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

You're not allowed to specify a different compiler program for different
packages within the same project. Given that in general we allow
specifying config about programs on a per-package basis this needs a
specific check.

Also add a place and a TODO for Future work in this area which is to
check up front that we can find the programs and to monitor them for
changes. Also, currently none of the program config ends up in the
package hashes, so it doesn't cause them to be rebuilt.

The solverSettingFlagAssignment does not need to be eliminated, it's ok
to have both, but make a note that it does need validating at some
point.

Move the FlagAssignment from the project-wide all-packages config to the
per-package config.

Initially it had been easier to do it globally since it gets used as a
solver setting rather than as the other per-package config items, but
obviously it is supposed to be per-package.

So the flags field in the config top-level now applies to all local
packages. And it can also be specified in package-specific sections.

We don't yet check that any of the flags specified actually make sense
for either the local packages or for the specific packages.

It's a Map PackageName PackageConfig (or LegacyPackageConfig) so the
correct monoid instance is to merge the PackageConfig values.

Both relative and absolute paths. That is, things like:

packages: this/
          ~/hacking/that/

Duncan Coutts authored Mar 25, 2016 and Mikhail Glushenkov committed Mar 27, 2016

File globs can now be absolute, e.g. starting with / or c:\
Also allow homedir relative, ie ~/

Globs can also have a trailing slash, in which case they only match
directories, not files.

Previously whether globs could match dirs was not totally consistent.
The matchFileGlob would match dirs, but the file monitor globs would
not. The file monitor globs can now match dirs (or with a trailing
slash, only match dirs). File monitors now also detect changes in the
file type, ie switching from file to dir or the other way around.

The file monitor are now pretty consistent between single file monitors
and globs monitors. They now have equivalent capabilities and share
code. For a single file or for a glob we can now control what we
monitor if the path is a file or a dir. In both cases we can monitor
mere existence, non-existence or modification time. For files we can
additionally monitor content hash.

File monitors now also detect changes in the file type, ie switching
from file to dir or the other way around.

New tests cover all these new file monitor cases. There are also new
tests for glob syntax, covering printing/parsing round trips.

(cherry picked from commit f6c1e71c)

Duncan Coutts authored Feb 16, 2016 and Mikhail Glushenkov committed Mar 17, 2016

This defines the new cabal.project files and introduces the notion of a
project root (and the logic for finding it). Also has support for
implicit projects when no cabal.project file is defined.

Supports both reading and writing project files or fragments. The
printing & parsing round trips correctly. QC tests to follow.

This is a key part of the new nix-local-build branch approach, based
around projects with clear configuration state held in a project file
(or extra files).

This has support for file and dirs as packages within a project,
including by glob. It supports both globs that much match a target, and
optional globs that are allowed to match nothing. It has partial support
for local tarball, remote http tarball and remote source repo packages.

(cherry picked from commit 324b3240)