On Wednesday 13 February 2008, Eric S. Raymond wrote: > Alexander Neundorf <[EMAIL PROTECTED]>: > > > A bigger one is that I think the two-level design -- cmake making > > > makefiles -- must inevitably have many of the same fundamental > > > weaknesses as autotools, Imake, and other makefile-generator systems. > > > I am intimately familiar with these and want to get away from that > > > approach. As far away as possible. > > > > What are the fundamental weaknesses ? > > You tend to get a lot of bugs and complexity right at the interface between > the levels, simply as the result of the fact that you're programming in one > language (cmake/Imake/autotools) and executing in another. Symptomatic of > this is generated makefiles that are huge and complex with lots of > mechanically generated productions. > > Imake and autotools are both notorious for this, and I would be > astonished if cmake does any better.
Of course it does ;-) I think building a small hello world is enough to get the idea: CMakeLists.txt: add_executable(hello main.c) $ cd src $ mkdir build $ cd build $ cmake .. Then check out what you find, the actual make-files are under the CMakeFiles/ subdir. > The problem is intrinsic, > deriving from the weakness of makefiles as a back-end language. CMake is not bound to make, it's "just" that currently for UNIX no other generator is implemented (the Eclipse, KDevelop and CodeBlocks generators also use the makefile generator). A generator which produces build files which are complete and an easy-to-process format would be nice to have. I don't know if such a format exists, maybe an ant generator for cmake might be a good candidate ? This would be xml and so the generated files would be easier to process by other tools. These other tools would be primarily the build tool (ant), and additionally this could be IDEs which could directly use the information, or a build library, so IDEs could use it and wouldn't have to call executables and parse their output. > > An advantage of cmake is that it doesn't only support generating > > makefiles, but also project files, e.g. KDevelop3, Eclipse, Xcode and > > Visual Studio, so developers used to these IDEs can continue using them. > > As long as scons or WAF can run on Windows, I think the single-tool > approach is better. For one thing, it avoids the temptation to > quick-fix problems by hacking the project files, Really, I never had to do this with cmake. ...but instead you can hack in some python code to do something weird. Having a domain specific language with limited functionality also has its advantages. (I think it doesn't make sense to discuss about this, both arguments are valid and it depends on the personal opinion which one is considered more important). Alex _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
