[Hackage] #459: Find out what we can learn from SCons

[Hackage]

#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