[LLVMdev] Keeping CMakeLists.txt up-to-date.

[Óscar Fuentes]

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
cpp files.

>  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
involved.

>>  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.

[snip]

-- 
Oscar