> > That's quite a presumption there. I can certainly write a module that > > compiles and produces documentation for Haddock but that is different > > when compiled into binary form. Even without this particular problem, > > I can see that being potentially useful. > > Sure, but it'd have to be a different cpp flag because the existing one > is used for a different purpose. >
But what purpose does __HADDOCK__ serve if not to inform a file of code that haddock is currently processing it? Perhaps even better would be a __HADDOCK_VERSION__ definition that allows for code to work through changes in the tool. While CPP may not be the most type-safe tool in the world and definitely not ideal for text macro substitution, it does do this simple kind of job very well. > This adventure has exposed a major problem with Cabal that I have run > > into several times. It supports a limited set of external tools (e.g. > > Haddock, Alex, Happy, etc.), but it supports them in a limited way. > > Primarily, it is not possible to pass options to these tools (at > > least) through the configure script. > > Don't you mean the other way around? It's not possible to pass extra > options to these tools via the .cabal file and it's only possible via > configure --$prog-options= > Sorry, when I said configure script, I meant .cabal file. Regards, Sean
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
