Duncan Sands wrote:> Do ordinary users need to have cmake if they want to build llvm? > If so, that's bad because they'll have to install it (unlike the > current setup, where only very standard tools are needed).That's not the only problem with cmake. The autotools may be a big and ugly beast, but that's because they're trying to solve a big and ugly problem for which there is no silver bullet. And they are still much more comprehensive than cmake. I've considered cmake time and again for my own projects, but I don't think that it's quite there yet. Here are some points worth considering: http://www.remlab.net/op/cmake.shtml (Some of these may already be addressed in newer cmake versions, I haven't checked recently.) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef <Dr.Graef at t-online.de> writes: [snip]> Here are some points worth considering: > http://www.remlab.net/op/cmake.shtml (Some of these may already be > addressed in newer cmake versions, I haven't checked recently.)Albert, Some points you mention on your web page are solved. Others are not applicable to LLVM. Others can be fixed within CMake itself (with some effort, of course). I lack the knowledge to judge the points you raise about distribution, package creation, etc. Finally, IMHO your concers about CMake not preserving as many [autotools] feautures as [it] can, does not apply to LLVM, at least as there is someone who vounteers to do the replication work :-) Please, some LLVM release manager (Tanya?), read Albert's web page and evaluate how much impact have the issues he raises on your work. -- Oscar
Óscar Fuentes wrote:> Albert Graef <Dr.Graef at t-online.de> writes: >> Here are some points worth considering: >> http://www.remlab.net/op/cmake.shtml (Some of these may already be >> addressed in newer cmake versions, I haven't checked recently.) > > [...] > > Please, some LLVM release manager (Tanya?), read Albert's web page and > evaluate how much impact have the issues he raises on your work.Note that the URL I referred to is not mine. I merely wanted to point out that there are some possible issues to consider before throwing the existing build system out of the window. Which might affect LLVM users for whom the current build system works fine, like me. :) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Óscar Fuentes wrote:> Some points you mention on your web page are solved.Which ones? (Just curious.)> Others are not applicable to LLVM.That might be the case now, but the lack of even basic functionality in some areas (in particular, no advanced feature checks, no make dist/distcheck, no make uninstall, lack of useful trace options when something goes wrong during a build, arcane user interface) might well become major roadblocks in the future. The broken mingw support (as pointed out by Stuart) would already be a major showstopper for me (and probably for many others who rely on mingw to ease the creation of native Windows ports). I do understand that you need a solution for MSVC where autoconf et al don't help much and cmake makes things much easier. But throwing out the current build system in favour of cmake is only a viable option if it works (at least) on all platforms supported by LLVM right now, as well as it does right now. That remains to be proven. Otherwise you just pass the buck from MSVC developers to everyone else. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag