Skip to content

Make Cabal-hooks more self-sufficient with additional re-exports#11772

Open
sheaf wants to merge 1 commit into
haskell:masterfrom
sheaf:hooks-exports
Open

Make Cabal-hooks more self-sufficient with additional re-exports#11772
sheaf wants to merge 1 commit into
haskell:masterfrom
sheaf:hooks-exports

Conversation

@sheaf
Copy link
Copy Markdown
Collaborator

@sheaf sheaf commented Apr 30, 2026

This PR adds several re-exports that make the Cabal-hooks library more self-sufficient, together with some additional helper functions findAndMonitorDirFileGlob and findAndMonitorSourceDirsFileExts that allow easily finding and monitoring files for use with pre-build rules.

TODO:


Template Α: This PR modifies behaviour or interface

@sheaf sheaf changed the title Hooks exports Make Cabal-hooks more self-sufficient with additional re-exports Apr 30, 2026
@sheaf sheaf force-pushed the hooks-exports branch 4 times, most recently from 1712eec to 81fc867 Compare May 4, 2026 10:12
@sheaf sheaf force-pushed the hooks-exports branch from 81fc867 to 3a984fe Compare May 6, 2026 12:16
Copy link
Copy Markdown
Member

@Mikolaj Mikolaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good otherwise. Thank you.

Comment thread Cabal-hooks/src/Distribution/Simple/SetupHooks.hs Outdated
Comment thread Cabal-hooks/src/Distribution/Simple/SetupHooks.hs Outdated
Comment thread Cabal-hooks/src/Distribution/Simple/SetupHooks.hs Outdated
@sheaf
Copy link
Copy Markdown
Collaborator Author

sheaf commented May 22, 2026

I rebased over the previous documentation improvements, so this is good to go now. Anyone else want to take a look?

This adds several re-exports that make the Cabal-hooks library more
self-sufficient, together with some additional helper functions
`findAndMonitorDirFileGlob` and `findAndMonitorSourceDirsFileExts` that
allow easily finding and monitoring files for use with pre-build rules.
searchDirs = hsSourceDirs $ componentBuildInfo comp
globText = case exts of
e NE.:| [] -> "**/*." ++ e
e NE.:| es -> "**/*.{" ++ intercalate "," (e : es) ++ "}"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking, we would need to escape those extensions before concatenating them into globs. The API would allow, for example, extensions like "*", "*/*", "}", "\\", etc., which would escape the extension context when injected into a glob like this (or simply produce a malformed glob).

globText = case exts of
e NE.:| [] -> "**/*." ++ e
e NE.:| es -> "**/*.{" ++ intercalate "," (e : es) ++ "}"
globEither = parseFileGlob (specVersion $ localPkgDescr localBuildInfo) globText
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may also be better to construct a Glob directly from the extensions, and then render that as a string (I believe this functionality already exists) to obtain globText, instead of using string concatenation to construct globText and then running that through the glob parser. This way, we not only avoid the above problem of pathological extensions breaking the glob syntax, we also don't need to handle any glob parser errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants