Find out what we can learn from SCons

[duncan]

 SCons is a build system for various languages. This task is to do some research to compare SCons to the build component in Cabal and find out what lessons we can learn from SCons.

The findings should be recorded on the SCons wiki page.

[bos]

I've used SCons quite extensively. I can't allow as how I have any good things to say about it.

[guest]

Yhc used SCons - and it really didn't help. By the end we had 10,000 lines of python build stuff related to scons. I don't think this will be a productive exercise, given I know that Duncan has already thought about this problem.

Yhc moved to SCons because KDE decided to move to SCons, and that seemed a good advert. After Yhc moved to SCons, KDE gave up and moved to CMake, perhaps CMake might be a better place to look for inspiration.

[duncan]

Replying to 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.