`cabal sdist` does not pick up files with multiple dots

[RyanGlScott]

I've distilled this example into https://github.com/RyanGlScott/cabal-sdist-bug/tree/910078306b4e127996bd7c9208a7e741b9f74351. This has a .cabal file with the following extra-source-files:

extra-source-files: check-hs/*.check.hs

And one can verify that there are indeed several files in that location with a .check.hs extension. But when one attempts to run cabal sdist on that project, cabal becomes confused:

$ cabal sdist
Warning: Cannot run preprocessors. Run 'configure' command first.
Building source dist for cabal-sdist-bug-0.1.0...
cabal: filepath wildcard 'check-hs/*.check.hs' does not match any files.

For some reason, cabal seems to get confused when the wildcard asterisk is used in conjunction with file extensions with multiple dots like .check.hs (at least, that's my current theory). In order to work around this bug, I have to manually enumerate every single .check.hs, like what I currently must do in base-compat.

$ cabal --version
cabal-install version 2.0.0.1
compiled using version 2.0.1.1 of the Cabal library

[hvr]

I don't know whether this was a deliberate design choice (maybe to discourage overzealous use of globbing? =) ) , but I remember Cabal behaving this way ever since it gained support for globbing... :-)

[RyanGlScott]

...OK? If this is intended behavior, how am I supposed to glob for these sorts of files?

[mitchellwrosen]

Here's the issue:

> parseFileGlob "check-hs/*.check.hs"
Just (FileGlob "check-hs/" ".check.hs")

So we're looking for .check.hs files, so far so good...

> splitExtensions "Control.Monad.Compat.check.hs"
("Control", ".Monad.Compat.check.hs")

Oops, we are looking for files with the .check.hs extension, yet Control.Monad.Compat.check.hs's extension is .Monad.Compat.check.hs.

[mitchellwrosen]

Here ya go #5061

[hvr]

Ok, I've investigated a bit, and the current behaviour was in fact a deliberate design choice (which I happen to sympathize with):

quoting 31f2678:

Fix the semantics of the simple file globbing to be sane

I realised when I started to document it that the behaviour
was not terribly consistent or sensible. The meaning now is:

  The limitation is that * wildcards are only allowed in
  place of the file name, not in the directory name or
  file extension. In particular, wildcards do not include
  directories contents recursively. Furthermore, if a
  wildcard is used it must be used with an extension, so
  "data-files: data/*" is not allowed. When matching a
  wildcard plus extension, a file's full extension must
  match exactly, so "*.gz" matches "foo.gz" but not
  "foo.tar.gz".

The reason for providing only a very limited form of wildcard
is to concisely express the common case of a large number of
related files of the same file type without making it too easy
to accidentally include unwanted files.

...and in fact, the same wording can be found in the user's guide at http://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-data-files

That being said, I realise that allowing *.tar.gz wildcards would not conflict with that rationale; it's just odd that the documentation didn't suggest a *.tar.gz wildcard for the foo.tar.gz example...

[quasicomputational]

Related bug: #784.