Correct. It could be broken down into two parts though: * One database containing facts about which GCC flags are incompatible with one another (i.e., cases wh

Correct. It could be broken down into two parts though: * One database containing facts about which GCC flags are incompatible with one another (i.e., cases where you can't specify both --foo and --bar). This would ideally be provided as part of the build system itself, since it's not going to change for every program built with the system. * A small database (if one is even needed) you'd specify in your build scripts where you can enumerate specific flags or compiler features you know shouldn't be used with your program. This would augment the database provided by the build system for your specific compiler. Note, I'm not suggesting that using Prolog to define a build system would make it impossible to specify bad or incompatible compiler flags. I am suggesting that deriving the set of flags to use for a build based on known facts about the compiler being used and your program makes it much less likely that a change you make to a build script causes the build to break in subtle ways once you've started compiling (or worse, at run-time). With Prolog, it'd be easier to detect such issues up-front so you can fix them before you start compiling or deploying.