#459: Find out what we can learn from SCons ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:1 bos]:
I've used SCons quite extensively. I can't allow as how I have any good things to say about it.
It doesn't have to be good overall for there to be things it does right. Conversely are there things it does that are obviously a mistake and we should avoid? Or perhaps we should just be comparing to a better example. Suggestions? It makes a number of design decisions. It's probably worth identifying some and trying to work out if they are good ideas. For example: * using content hashes instead of timestamps for rebuilds * using a clean environment to run build commands, with a way to explicitly let in certain environment variables. The idea seems to be to get more repeatable portable builds by tracking dependencies. Related to #458. * separating CPPFLAGS from CCFLAGS to be able to find and track changes in header files. We also split them this way. Or APIs it provides to custom build scripts: * simple support for `foo-config --cflags --libs` style programs * autoconf like functions to check C header files, libs etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/459#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects