Most (all?) of the build systems out there today (make, CMake, rake, etc.) are declarative but they lack Prolog's inference capabilities. This gives a specific advantage -- it allows you to reduce fragility of your build system by making it dead simple to tell when you've combined incompatible configuration options (e.g., compiler flags) which you might otherwise discover halfway through a long build.
For a quick overview, check out the paper prom: A flexible, Prolog-based make tool.
Two things that you'd get, that to the best of my (limited) knowledge aren't possible in make, is having cut, and the notion of both "and" and "or" - not only can you declare multiple dependencies and rules, but also "alternative" rules in case one does not succeed (e.g., in case you shell-out to a non-existent binary, try a different one).
* 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.