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