CMake for D2 ready for testers

[SK]

On Mon, Sep 6, 2010 at 1:53 AM, Nick Sabalausky <a at a.a> wrote:
> "Jonathan M Davis" <jmdavisprog at gmail.com> wrote in message
> news:mailman.114.1283754439.858.digitalmars-d at puremagic.com...
>> On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote:
>>>
>>> Not to be contentious, just curious about the design philosophy behind
>>> cmake: Why is it a layer on-top of make at all instead of just bypassing
>>> the antiquated make altogether? GNU autotools does the same thing (ie,
>>> "fix" make by just adding more layers on top of it), and that always
>>> struck me as silly. Is there some particular reason for this approach?
>>
>> cmake can generate a variety of different build system files, including
>> both
>> makefiles and visual studio project files. So, you can use the same cmake
>> files to
>> generate build stuff for multiple OSes. Also, it's a lot cleaner and
>> simpler to
>> set a lot of stuff up then it is in makefiles. When KDE was using
>> autotools, they
>> pretty much couldn't do a Windows version because it would have been too
>> disgusting to alter them as necessary. However, after having switched to
>> cmake,
>> they could do it. I haven't used it a whole lot at this point, so I'm not
>> sure
>> of all of the ins and outs, but it's a lot more pleasant to deal with than
>> makefiles, and it's a lot more flexible.
>>
>
> Well, I guess what I mean is, compared to something like SCons, Rake or
> A-A-P. Those tools, like cmake, handle cross-platform no problem while
> providing far saner syntax than traditional make. But unline cmake, they
> don't have any reliance on traditional make even on unix. Granted, they
> don't generate IDE project files, but my initial impression of that is
> importing information *from* IDE project files would seem to be a more
> practical approach.
>
> From what tiny bit I read on the site (it seemed suprisingly hard to find
> the documentation on the site, but maybe that was just me), it does seem
> heavily C/C++ centric, and so it looks like it may be able to handle
> different C/C++ compilers fairly well. By contrast, SCons and Rake, as far
> as I can tell, don't seem to have any specific provisions for abstracting
> different compilers for a single language (though A-A-P does try to do
> that). So maybe that has something to do with it?
>
> Again, I hope I'm not coming across as challenging the usefulness or quality
> of cmake - that's not my intent. Just curious about why it chooses not to
> ditch traditional-make entierly like some of the other build systems do.
>

Hi Nick - Yes, it's certainly a debatable question but I can't offer
special insight.  Skipping my own long and checkered experiences with
build systems, I'll say that CMake has been the first to reach the
lofty level of "satisfactory".

Some related reading:
Why KDE switched to cmake: http://lwn.net/Articles/188693

The CMake documentation is OK.  90% of the time I look here:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html

The command line --help is extensive.
Regards,
-steve