I've used SCons quite extensively. I can't allow as how I have any good
#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]: 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