Additionally, ghc --make lacks (AFAIK) several useful features found in other make tools (although not all in the same tool...):
1. The ability to distingush directories containing source code to be compiled from directories containing previously compiled code (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess you could use -package-conf as a cumbersome substitute, though.)
2. The ability to specify compiler flags for individual modules without putting them in the source code. (Some flags are 'static' and can not be put in the source code.) 3. The ability to compile several modules in parallel, on a multi-processor machine, or a network of workstations. 4. The ability to automatically invoke program generators (e.g. happy)... 5. A graphical user interface.
All valid arguments, of course. But in --make's favour, it *is* much faster than individual compiles. In a little test I did today, ghc --make beats hmake/nhc98 on a reasonably sized program (nofib/real/anna). I timed both with -H32m and no optimisation, ghc --make compiled it in 48 seconds compared to 51 seconds for hmake/nhc98. On small individual modules, nhc98 wins hands down though. Ok, so speed isn't everything, and I hear the arguments you enumerated above. Most of these can be achieved through extra compiler support, and the last one (a make GUI) should actually be easier with GHC once we get around to specifying the compiler's programmatic API more precisely. Cheers, Simon
Hi! I would like to add a request to Thomas list of lacking features of ghc --make: When caching information between the compilation of different modules, use weak pointers. With large projects, ghc runs out of heapspace because of too much caching. It's always fine to restart the build process by doing ghc --make again but the whole thing is really annoying. I agree that caching is important and very nice, but it shouldn't make the building process to abort. /Josef On Mon, 8 Oct 2001, Simon Marlow wrote:
Additionally, ghc --make lacks (AFAIK) several useful features found in other make tools (although not all in the same tool...):
1. The ability to distingush directories containing source code to be compiled from directories containing previously compiled code (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess you could use -package-conf as a cumbersome substitute, though.)
2. The ability to specify compiler flags for individual modules without putting them in the source code. (Some flags are 'static' and can not be put in the source code.) 3. The ability to compile several modules in parallel, on a multi-processor machine, or a network of workstations. 4. The ability to automatically invoke program generators (e.g. happy)... 5. A graphical user interface.
All valid arguments, of course. But in --make's favour, it *is* much faster than individual compiles. In a little test I did today, ghc --make beats hmake/nhc98 on a reasonably sized program (nofib/real/anna). I timed both with -H32m and no optimisation, ghc --make compiled it in 48 seconds compared to 51 seconds for hmake/nhc98. On small individual modules, nhc98 wins hands down though.
Ok, so speed isn't everything, and I hear the arguments you enumerated above. Most of these can be achieved through extra compiler support, and the last one (a make GUI) should actually be easier with GHC once we get around to specifying the compiler's programmatic API more precisely.
Cheers, Simon
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (2)
-
Josef Svenningsson -
Simon Marlow