The F5 key is not a build process
In my opinion, building software is the most important part of the development process besides developing the actual code. I think this is even more important than bug tracking. To me, a build process must:
- Be fully automated aka "Push-button builds"
- Only depend on source (no pre-built tools or libraries thank you very much)
- Run sanity tests
- Be able to run torture tests
- Build a package you can ship to QA or clients
Usage requirements are essentially a neat way of saying: If you are going to use this module, then you should use these flags to compile. For example, if I was using static library A to create executable B, A might require me to add -DUSING_LIBA_STATIC=1 to the command line (and will most definitely require some linker flags.) In traditional build systems, this logic would be forced on the client usage in some annoying way:
# pseudo-makefile syntax
app: libA.a main.cpp
$(CC) $(LIBA_CCFLAGS) $(LIBA_LINKFLAGS) main.cpp -o app
Not bad but it can quickly get redundant and complex when the number of libraries grows. With Boost Jam:
exe app : main.cpp /path/to//libA ;
Thats it. Pretty neat eh? This is one feature that I sorely wish existed in SCons. However, it is possible to approximate the above:
I just prototyped something like this last night that handled propagated usage requirements. I doubt I will need the full power of Boost Jam usage requirements, but even just being able to have the logic in one place would make life a lot easier for me.
I have yet to decide whether it is a kludge or an elegant hack :-)