CMake for D2 ready for testers

[Nick Sabalausky]

"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:
>> "SK" <sk at metrokings.com> wrote in message
>> news:mailman.113.1283750971.858.digitalmars-d at puremagic.com...
>>
>> > Why labor over buggy Makefiles when you could be laboring over buggy
>> > CMake files at a much more productive level of abstraction?  :o)
>> >
>> > With excellent help from Jens Mueller and Dean Calver, CMake for D2
>> > now passes our small suite of unit tests on both Windows and Linux.
>> > Our tests include mixed C-D applications and libraries.  We tested
>> > with CMake 2.8.2 and DMD 2.048.  We'd appreciate if a few hardy souls
>> > were willing to take a test drive.  Check it out here:
>> > http://code.google.com/p/cmaked2.  Please report problems on the
>> > cmaked2 tracker rather than here.
>> >
>> > Unfortunately, we have not had an opportunity to test on Mac OS's.
>> >
>> > Briefly, CMake is a cross-platform "make maker".  Many people find
>> > CMake more attractive than traditional Makefiles or Autotools,
>> > especially for large projects.  You can find more information here:
>> > http://www.cmake.org.
>>
>> Interesting, I had no idea cmake generated makefiles. (For that matter, I
>> had no idea cmake was anything more that yet another version of make, 
>> like
>> nmake, GNU make, etc.)
>>
>> 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.