ghc --make -odir x -hidir x chooses strange location for x
I'm a great fan of ghc --make, but there seem to be a few features that could be improved: 1) -odir x (same for -hidir) seems to put all object files into a directory x relative to the call to ghc.. Well, I wanted .o files out of the way, but not that far out of the way! Not only do all .o files for the source file hierarchy end up in one directory, that directory has no relation to the source file location. So, even if I don't get name conflicts in that one directory, as soon as I reuse part of my source directories for a second project, that'll end up compiling its own copies of the .o files. Unless I put all .o files for all my projects in the same directory.. I'd have expected -odir/-hidir to put files in directories relative to the source directories. Is that an unreasonable expectation? 2) with static options not accepted in source file pragmas, I often end up compiling everything with the superset of options. Shouldn't it be possible to fork a new copy of ghc with new static options for parts of a ghc --make run? 3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)? The standard examples are happy, cpp, drift, .. Just a few suggestions, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/
"Claus Reinke"
3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)?
The standard examples are happy, cpp, drift, ..
If you are willing to switch from ghc --make to hmake, you get various common suffix rules for free. .y -> Happy .ly -> literate Happy .hs.cpp -> cpp .gc -> GreenCard .hsc -> hsc2hs .chs -> c2hs It is also relatively straightforward to add more pre-processing rules of this nature to the hmake sources. For example, do you have a suggestion for a DrIFT suffix? Regards, Malcolm
3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)?
The standard examples are happy, cpp, drift, ..
If you are willing to switch from ghc --make to hmake, you get various common suffix rules for free. ..
It is also relatively straightforward to add more pre-processing rules of this nature to the hmake sources. For example, do you have a suggestion for a DrIFT suffix?
.hs.d? Strafunski uses .ds .. hmm, perhaps I'll have another look at hmake. It's just nice to get going without extra tools (and without autoconfigured non-portable self-remaking recursive humbug..; no, I'm not thinking of hmake here, but some people simply get carried away when they encounter gnu-make&family;-). In the interests of portability, your ads for hmake are of course justified. The following may not apply to hmake, but while we are off the topic: the main problem I have with Makefiles of any sort is that they store a lot of information about my programs outside of the language tools. For instance, Haskell doesn't specify a common notion of a Haskell project, so this is currently either hidden in Makefiles or in all kind of tool-specific ad-hoc constructions for IDE-like things and similar tools. It would be nice if everything that's needed to understand a set of Haskell source files would be accessible from the sources (perhaps with the addition of some Haskell project specifications in a format pinned down in the language standard). That this isn't the case indicates that there are things missing from Haskell that are needed in practice (the common use of the _C_ preprocessor to selectively enable platform- or implementation-specific code is another sore point), and while there have been language-external ways around that, the differences that evolved from those ways are now in the way of further developments, such as IDEs (unless you're happy to be locked into one of them?). Cheers, Claus
participants (2)
-
Claus Reinke -
Malcolm Wallace