[LLVMdev] Keeping CMakeLists.txt up-to-date.
ofv at wanadoo.es
Sun Oct 26 13:34:17 PDT 2008
Kenneth Boyd <zaimoni at zaimoni.com> writes:
>> 1) either CMake becomes the de facto standard for LLVM, deprecating
>> autoconf&&gmake and thus requiring the developers to update the
>> CMakeLists.txt files to compile their sources...
> Sorry, but this is a noticeable obstacle for CMake becoming the de-facto
> standard for LLVM.
Writing a new cpp file: minutes to hours.
Adding it to its corresponding CMakeLists.txt: less that 10 seconds.
I created the CMakeLists.txt files for all Clang source tree yesterday
in less than 15 minutes, and it involved much more than writing lists of
> From the existence of the dependency-tracker scripts, it obviously was
> a problem for autoconf as well.
This seems a different issue, but are those dependency-tracker scripts
for tracking dependencies among cpp files and its headers? CMake gives
you this for free and it is not restricted to gcc.
>> If the tendency is towards (2), I'll implement a cmake option for
>> checking that the files contained in each CMakeLists.txt matches those
>> on its respective directory, reporting the differences.
> I think this option would be useful anyway.
Agreed. But right now I prefer to avoid adding features that would
justify any kind of inaction by the developers. I want get them
>> Checking the
>> discrepancies is easy, patching the CMakeLists.txt file is not, in the
>> general case, either for a Perl script or for CMake itself.
> The general case doesn't matter.
It matters a lot. One nice thing about CMake is that it provides means
for abstracting things. So you see add_llvm_library, which is
llvm-specific macro, instead of the standard add_library. Assuming that
add_llvm_library will work on the future as it works now would lead to
problems at some point.
More information about the llvm-dev