Ticket #213 (closed enhancement: fixed)

Opened 10 months ago

Last modified 4 months ago

allow wildcards in data-files or extra-source-files?

Reported by: duncan Assigned to:
Priority: normal Milestone: Cabal-1.6
Component: Cabal library Version: 1.2.3.0
Severity: normal Keywords:
Cc: Difficulty: very easy (<1 hour)
GHC Version: 6.8.2 Platform:

Description

Some packages end up with very very long fields for data-files or extra-source-files. Is this a problem? Should we allow some kind of globing to make it a bit less verbose?

extra-source-files: cbits/*.h
c-sources: cbits/*.c

On the other hand, there is a danger with globing that you pick up too many files. Perhaps we can counter that by making the globing rather restrictive, like no subdirectory recursion, and only allowing *'s in the final directory component, so no data/*/* patterns. Is there a sweet spot that allows conciseness without including too much accidentally?

Change History

06/19/08 06:11:39 changed by duncan

  • difficulty changed from normal to easy (<4 hours).
  • milestone set to Cabal-1.6.

06/25/08 11:00:51 changed by tphyahoo

yes, please do this.

It would be helpful to my my cabalized happs-tutorial.

06/26/08 10:19:17 changed by duncan

Done, though not heavily tested:

Thu Jun 26 18:14:24 BST 2008  Duncan Coutts <duncan@haskell.org>
  * Add simple file name globbing (*) to data-files and extra-source-files

I've not added it to c-sources. We can change that if we think it's important.

For example in happs-tutorial.cabal:

Extra-Source-Files:
    runServer.sh
    templates/*.st
    static/tutorial.css
    static/HAppSTutorialLogo.png

which is considerably neater than the previous long list.

06/26/08 10:19:48 changed by duncan

  • difficulty changed from easy (<4 hours) to very easy (<1 hour).

Still needs to be documented.

07/29/08 09:28:46 changed by duncan

Tue Jul 29 16:26:24 BST 2008  Duncan Coutts <duncan@haskell.org>
  * 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.

Tue Jul 29 16:40:50 BST 2008  Duncan Coutts <duncan@haskell.org>
  * File globs must match at least one file or it's an error.

Tue Jul 29 16:59:20 BST 2008  Duncan Coutts <duncan@haskell.org>
  * Document the wildcard behaviour in data-files and extra-source-files fields

I'm still not completely sure about the semantics of matching file extensions. Currently *.gz matches foo.gz but not foo.tar.gz, on the theory that foo.tar.gz has the extension tar.gz and that's not the same as the extension gz.

The problem with this, apart from the above example is things like foo-1.0.gz where the full extensions is 0.gz and so again would not be matched by *.gz.

The alternative I suppose would be to match any of the list of extensions. So for example foo-1.0.1.tar.gz has the extension list ["gz", "tar.gz", "1.tar.gz", "0.1.tar.gz"] and we'd match *.gz by checking if gz` was a member of that extension list which of course it is.

Opinions?

07/29/08 11:37:25 changed by duncan

  • status changed from new to closed.
  • resolution set to fixed.

Igloo reckons this behaviour is ok so I'm leaving it there. It is documented with the current behaviour.