[Haskell-cafe] Re: How to make cabal pass flags to happy?

[Duncan Coutts]

On Wed, 2010-10-20 at 10:37 +0200, Niklas Broberg wrote:

> > I think the "right solution" is for the happy source file to specify
> > what kind of grammar it is / should be produced. Yes, that would mean
> > modifying happy.
> 
> Hmm, I agree with you in this particular case, regarding the grammar,
> since it really only makes sense for any given happy grammar to
> generate either kind of parser. But such a solution still wouldn't
> answer the general question about passing flags to preprocessors.
> Certainly not all such use cases are best fixed by pushing the flags
> into the pre-processed files.

I like to see it as an issue of the design of the whole system, not just
adapting cabal to existing half-thought-out tools.

With preprocessor flags the first question is who picks the flags. If it
is the person doing the build then we handle that already. If it is the
package author then it needs more careful analysis. Yes we could go and
add a foo-options for every single pre-processor but that's not
obviously a good idea.

Yes you can have full control by writing code in the Setup.hs (and it
could be easier to do that) but again it's not a very nice solution in
general. I think we have a habit of just adding flags to such tools and
saying "let the build system handle it" without really thinking
carefully about where the right place to specify things should be.

My view is that for the most part, source modules ought to be
self-descriptive so that they can be built with zero configuration. For
basic Haskell modules we do this already, we have a standard convention
on file extension, file <-> module name mapping, language pragmas, etc
etc. This is what allows ghci / ghc --make to work in most cases (and in
principle should allow a future cabal to work even without a .cabal file
for many simple projects -- like hmake did for years).

For preprocessors we have some convention, we mostly use file name
extensions. For more detailed variations I think it does make sense to
stick it in the source module. The harder cases are things like
preprocessors which genuinely have multiple modes. I don't mean things
like happy's GLR since as I understand it you really design the grammar
specifically for the approach. There are other tools where from the same
source you can and do generate multiple outputs. There it is harder to
establish a convention that allows for zero-configuration.

Similarly, documentation is a mess because there are few established
conventions, so much more grungy configuration is needed.

Duncan