ghc --make -odir x -hidir x chooses strange location for x

Claus Reinke claus.reinke@talk21.com
Wed, 23 Oct 2002 22:38:06 +0100


> > 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