
Hey all. Just thought I'd give an update... Cabal now does something [1] for preprocessors, though it's perhaps not perfect. I need a real test case, a smallish program that uses a preprocessor (except for cpp, which isn't yet supported). Any suggestions? Something that uses happy perhaps? Once I have such an example, and get cpp working nicely, then I'll release 0.2. Here's the cabal web page: http://www.haskell.org/cabal/ You can of course see what I have now by using darcs to check out the repository. On Debian simply: % apt-get install darcs % darcs get http://cvs.haskell.org/darcs/cabal peace, isaac [1] Foo.y is a happy grammer which, when processed, will produce Foo.hs. The description file should include the module Foo. ./setup sdist (source distribution): Include Foo.y, not Foo.hs. Maybe we could add a flag to include Foo.hs as well. This makes sense for some preprocessors and not for others, but I'm wary of including too much preprocessor-specific behavior. ./setup clean: Removes Foo.hs if Foo.y exists. ./setup build: Preprocesses Foo.y to Create Foo.hs before any compilation. The issue with cpp is that we can't go by extensions as we do with the rest of the preprocessors... There is a function in HMake which tests to see if a file needs to be cpp'd, so we can employ that. I think we'll probably have to just treat cpp a little differently from the others, unfortunitely, and I haven't gotten around to it.

Isaac Jones
The issue with cpp is that we can't go by extensions as we do with the rest of the preprocessors... There is a function in HMake which tests to see if a file needs to be cpp'd, so we can employ that. I think we'll probably have to just treat cpp a little differently from the others, unfortunitely, and I haven't gotten around to it.
On the other hand, you could reject the convention that cpp sources are not distinguished by file extension - e.g. create a new convention that, say, a .cpphs extension is preprocessed by cpp(hs) to get a plain .hs file. Since Cabal is pretty new, this won't break any existing Cabal packages, and when converting non-Cabal packages to Cabal, there is some work to do anyway, so why not just adopt this as one extra rule to follow? This is just a suggestion - I'm in two minds whether it is a good idea myself, but it is at least worth considering the possibility. Regards, Malcolm

At 09:57 19/10/04 +0100, Malcolm Wallace wrote:
Isaac Jones
writes: The issue with cpp is that we can't go by extensions as we do with the rest of the preprocessors... There is a function in HMake which tests to see if a file needs to be cpp'd, so we can employ that. I think we'll probably have to just treat cpp a little differently from the others, unfortunitely, and I haven't gotten around to it.
On the other hand, you could reject the convention that cpp sources are not distinguished by file extension - e.g. create a new convention that, say, a .cpphs extension is preprocessed by cpp(hs) to get a plain .hs file.
+1 This is exactly what I do for my own code, e.g., http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXm... which is processed to: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXm...
Since Cabal is pretty new, this won't break any existing Cabal packages, and when converting non-Cabal packages to Cabal, there is some work to do anyway, so why not just adopt this as one extra rule to follow?
This is just a suggestion - I'm in two minds whether it is a good idea myself, but it is at least worth considering the possibility.
I adopted this convention so I could run the cpphs software separately without zapping any original files. I'm not aware of any downside. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
participants (3)
-
Graham Klyne
-
Isaac Jones
-
Malcolm Wallace