There appears to be a coupling between the RESULTS of the LLVM build strategy and the KLEE build strategy.
That is during the KLEE build, files created during the LLVM build are imported. The information utilized appears to be directory locations and aspects of the environment analysis (libraries present, utilities present, etc.). This creates a state coupling which I find to be perverse. That is the state of the OS resource environment can change between the time when the LLVM build occurred and the KLEE build is to occur. KLEE would consequently be built with an inaccurate evaluation of the OS environment As an example. Build LLVM, install dejagnu, Build KLEE will NOT result in the execution of the dejagnu based regression test of KLEE; whereas install dejagnu, build LLVM, build KLEE will result in the execution of the KLEE regression test. Stateless build strategies are preferable to those which have states. Much easier to debug problems. Importing the configuration rules of LLVM into the configuration of KLEE probably will probably remove the state dependency, but it will probably result in a rule maintenance nightmare. dbl
