[LLVMdev] CMake builds clang.

[Kenneth Boyd]

Óscar Fuentes wrote:
> Kenneth Boyd <zaimoni at zaimoni.com> writes:
>
>   
>>>> Isn't is possible for cmake just to glob everything in the corresponding
>>>> directory?
>>>>     
>>>>         
>>> Yes, but then the build would not notice a change on the file
>>> structure. You'll need to explicitly invoke cmake for being sure that
>>> whatever changes were made by the last svn update are reflected on the
>>> generated makefiles, which is a bigger incovenience than the occassional
>>> modification of the CMakeLists.txt file.
>>>   
>>>       
>> It would be simpler for autoconf builds to have a Perl script that 
>> updates the CMakeLists.txt files when necessary.  (This doesn't look 
>> *that* hard, but I can't say when I'll surface long enough to work on that.)
>>     
>
> In theory, it is possible to do this with cmake itself. In practice, it
> doesn't matter much because:
>
> 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.

 From the existence of the dependency-tracker scripts, it obviously was 
a problem for autoconf as well.
> 2) ... or CMake remains a fall-back system for those not covered by
> autoconf&&gmake, with most LLVM developers ignoring it and requiring
> some periodic maintence work by those who use it.
>
> 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.
>  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.

The specific case we're talking about appears easy (in Perl: it's just 
adjusting *one* variable in the CMakeList.txt), and as I see the 
development workflow critical for option 1.

Kenneth