Ó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
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
Óscar Fuentes wrote:> Kenneth Boyd <zaimoni at zaimoni.com> writes: > > > ..... >> 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. >GenLibDeps.pl tracks direct dependencies between the primary library and object files intended to be linked (*.a and *.o on a *NIX-like system). Other parts of the LLVM build modifications to autoconf walk this to determine which libraries have to be linked in. Kenneth