On Sunday 18 May 2008, Óscar Fuentes wrote:> Chris Lattner <sabre at nondot.org> writes: > > [snip] > > > Others have suggested alternative build systems before like cmake. > > Apparently cmake can autogenerate VC++ and Xcode project files from > > the same thing that it builds from on unix systems. > > cmake creating VC++ project files does not appeal much to me. First, > project files are not mandatory for using MS compiler.cmake can create nmake files as well. It's also possible to add a different generator that use something else (even one that would output to gmake and use msvc compiler and gcc for header dependencies ;) ).> Second, I'm > afraid that things like intermediate script invocations may be > translated incorrectly to VC++ projects.Calling external program works correctly, I am not sure why it woud be different for script invocations.> > Has anyone used cmake in a real system before?Kitware (the creators of cmake) products (VTK and ITK), KDE, scribus, inkscape for the biggest project I know which use cmake. All of them use it for building on windows, mac os x and unixes. But, at least, for KDE, I am not sure if for mac os x, anyone has try to use it with Xcode. Personnally, I use cmake for building a project (OpenGTL) that link to llvm. -- Cyrille Berger
Cyrille Berger wrote:> On Sunday 18 May 2008, Óscar Fuentes wrote: >> Chris Lattner <sabre at nondot.org> writes: >> >> [snip] >> >>> Others have suggested alternative build systems before like cmake. >>> Apparently cmake can autogenerate VC++ and Xcode project files from >>> the same thing that it builds from on unix systems. >> cmake creating VC++ project files does not appeal much to me. First, >> project files are not mandatory for using MS compiler. > cmake can create nmake files as well. It's also possible to add a different > generator that use something else (even one that would output to gmake and > use msvc compiler and gcc for header dependencies ;) ).For what it's worth, I think that using a system like cmake, while lessening the load of the LLVM developers, increases the load on users of LLVM. I'm building a piece of software and I have to deal with each external dependency using it's own favourite build system - the end result is that to build my software I have to use SCons, bjam, cmake, Visual Studio _and_ nmake. In my opinion the best solution is if the software comes with project files/makefiles that are 'native' to the platform you're building on and doesn't require any extra software to be installed before you can build. I've had good results with using scripts to keep .vcproj files updated in order to synchronize project files between different versions of Visual Studio. The same method should be applicable to synchronizing with makefiles and XCode project files. If anything more complicated than adding/removing files need to be done, it can be done by hand - but that's pretty rare anyway. m.
Hi> For what it's worth, I think that using a system like cmake, while > lessening the load of the LLVM developers, increases the load on users of > LLVM.Well if it is easy to use, i don't think that is a problem? Besides is extendig llvm also an "use case" in this sense?> In my opinion the best solution is if the software comes with project > files/makefiles that are 'native' to the platform you're building on and > doesn't require any extra software to be installed before you can build. > I've had good results with using scripts to keep .vcproj files updated in > order to synchronize project files between different versions of Visual > Studio. The same method should be applicable to synchronizing with > makefiles and XCode project files. If anything more complicated than > adding/removing files need to be done, it can be done by hand - but that's > pretty rare anyway.You are only talking only about specific development environments. I think this is more problematic than a tool like cmake which can be used on every plattform? Besides of that the scripting engine which does these modifications needs also to be installed. So in the end it boils down to personal preference which script language you have installed per default. ST