Óscar Fuentes wrote:> "Anton Korobeynikov" <asl at math.spbu.ru> writes: > > >>> at all, it would be great if you reflect your changes on the file list >>> inside the corresponding CMakeLists.txt when you add, remove or rename >>> a .cpp file. >>> >> 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.) Kenneth
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... 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. 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. So, Kenneth, don't waste your time on this. -- Oscar
Ó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
On Oct 26, 2008, at 11:17 AM, Óscar Fuentes wrote:>> 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...FWIW, when it is ready, I'd strongly prefer to use cmake for everything. We should have one build system to rule them all, and the whole reason that cmake seems awesome is that it covers all the build hosts we care about. That said, I don't really think the file globbing is that big of a "feature". If it turns out that we don't get it with cmake, that's ok. -Chris