eborden / filepattern Goto Github PK

Currently when matching a FilePattern and FilePath, if there is a . in the FilePattern, that can either match a literal . in the FilePath, or be ignored. Conversely, every . in a FilePath must be matched explicitly or with something like * or **. That behaviour is confusing and weird. I see two sensible possible routes forward:

1. Ignore all . paths in both FilePattern and FilePath.
2. Declare that . has no special behaviour in either - it can be matched literally, but nothing else.

The concern with option 2 is that when walking a directory structure, . really does have no meaning, so it is a bit inconsistent. The concern with option 1 is that it's magic behaviour that isn't otherwise well founded. Thoughts? (CC @eborden and @snowleopard)

The Shake paths, as per ndmitchell/shake#376, don't match absolute paths - so **/*.c will match test/foo.c but not /test/foo.c or C:/test/foo.c. While it's somewhat useful, it's highly inconsistent in the code, and requires deciding whether C:foo.c or /foo.c are relative or absolute on Windows (in truth they are bit of both...). My inclination is that when moving to a filepattern library that whole relative/absolute mess should be thrown out, and **/foo.c should be equivalent to takeFileName x == "foo.c", regardless of absolute vs relative.

My thoughts are that if people want to avoid matching relative paths in their Shake build system they can do:

priority 100 $ isAbsolute ?> \_ -> return ()

Namely add a rule with top priority that always matches absolute paths and doesn't build them.

I did a dummy removal of the absolute/relative stuff and a lot of tests got simpler, in particular those about walker and ?== correspondence, which certainly suggests it is the right semantics.

CC @eborden @ezyang @snowleopard

Let's release filepattern on hackage. What is left to do?

@ndmitchell In this comment you mentioned wanting to make other changes. Could you enumerate them here so that they can be tackled?