using ghc with make

[Frederik Eaton]

Hi! I almost forgot that I never responded to this, sorry.

On Tue, Apr 18, 2006 at 11:37:12AM +0100, Simon Marlow wrote:
> Frederik Eaton wrote:
> >I have a project which currently uses Cabal, and I would like to
> >switch to using a plain Makefile. I have two examples of projects that use Makefiles, darcs and jhc, 
> >but
> >they both appear to hand-code the list of dependencies for
> >executables. The "-M" option to ghc should let us do this
> >automatically, but either because of a deficiency in GHC or in GNU
> >Make, that looks to be impossible or difficult. Does anyone have
> >experience with this?
> 
> Yes, GHC's build system works like this. We don't use --make at all
> when building GHC itself. However, I want to switch to using Cabal
> to build the libraries. Eventually I envisage using Cabal to build
> more parts of the GHC tree.
> 
> There's certainly no reason that you can't use ghc -M with GNU make, and that's something we will 
> continue to support.  What problems are you having?

OK, here:

http://www.haskell.org/ghc/docs/6.4.2/html/users_guide/separate-compilation.html

There is a section

----------------------------------------------------------------
SRCS = Main.lhs Foo.lhs Bar.lhs
OBJS = Main.o   Foo.o   Bar.o

...

cool_pgm : $(OBJS)
        rm -f $@
        $(HC) -o $@ $(HC_OPTS) $(OBJS)
----------------------------------------------------------------

and below that a section:

----------------------------------------------------------------
# Inter-module dependencies
Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz
Main.o Main.hc Main.s : Foo.hi Baz.hi   # Main imports Foo and Baz
----------------------------------------------------------------

Then, the documentation explains how to get rid of the second section
using 'ghc -M'. But IIRC it doesn't explain how to get rid of the
first part, which includes information that 'ghc --make' doesn't
require. Does that make sense? I may have it wrong/backwards.

Also, it would be useful to know about dependencies on libraries. 
Basically, the best possible situation would be if 'ghc' gave me a
list of everything whose {timestamp,checksum}+dependencies I should
check to make sure that an output file is up to date (but not in a
flattened form - i.e. for each file, only the *immediate* dependencies
should be listed, and those can have their own dependencies, etc.). 
Even better would be to know which environment variables have been
referenced by the compiler, and which directories in a search path
mustn't have modules of a certain name (since those modules would have
otherwise been used in preference to the ones which were actually
used). Then it would be possible to just store every output file of
'ghc' in a cache in my home directory, and for instance switching
between normal and profiling builds wouldn't require recompiling
anything (or creating a separate project directory for each set of
options) as it does in the current system. I don't think this is a
very high priority, but I think that having 'ghc' duplicate more of
'make's functionality is kind of going in the wrong direction - I
think compilers and build systems need to be able to evolve
separately.

> >Since I'm not using the multi-compiler features of Cabal, I think it
> >shouldn't be too hard to get the project-specific part of my Makefile
> >down to the size of the .cabal file.
> 
> Sure, but you also have a quite a lot of build system infrastructure to get right.  Incedentally, 
> this is exactly what Cabal was meant to avoid.
> 
> >- I want to be able to rebuild specific targets, rather than building
> >everything every time
> 
> Multiple Cabal packages tied together with a simple Makefile could do this, no?

Yeah, but it would require me to put things in separate directories.

> ...
> I think it would be prudent at some point to make Cabal build without --make and to add 
> multiprocessor support.

It's more than just multiprocessor issues I'm thinking about - for
instance I might like to do a distributed compilation, or I might like
to cache output in a special place as I suggested above. I think it
would be very nice, someday, if 'Cabal' could provide dependency
information, or for instance a list of which commands it's going to
invoke to produce which files, so that the build system and
compiler/packager are not tied together.

Best regards,

Frederik

-- 
http://ofb.net/~frederik/