hvr
commented
9 years ago While this would seem to be convenient as a workaround for cabal-install, it would at the same time complicate packaging for things like my GHC PPA (which packages alex and happy), where I would need to split alex into several packages for each GHC version, as well in general if you have multiple GHCs installed, and switch between them (as you'd have to reinstall alex for each of them to have the library visible in their respective pkg-db, and then you'd have to install alex globally, as otherwise sandboxes wouldn't see the alex library and you'd have again to rebuild alex for each sandbox otherwise)
In summary, I don't think this is a good idea to artificially attach a library to alex for the sole purpose of workarounding a cabal-deficiency which will hopefully be addressed at some point upstream, see also haskell/cabal#220
alanz
At the moment cabal does not enforce build-tools clauses.
This cause a problem for language-javascript, which is a deep dependency in the yesod family, and it often fails to install due to a missing alex (and happy), as per https://github.com/yesodweb/yesod/issues/747
How about creating a tiny library that is part of the alex package, perhaps with a single function to return a version number, so that the dependencies can be managed in the normal way.
cc @snoyberg