www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CMake for D2 ready for testers

reply SK <sk metrokings.com> writes:
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.

Cheers,
-steve
Sep 05 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"SK" <sk metrokings.com> wrote in message 
news:mailman.113.1283750971.858.digitalmars-d 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?
Sep 05 2010
parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote:
 "SK" <sk metrokings.com> wrote in message
 news:mailman.113.1283750971.858.digitalmars-d 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. - Jonathan M Davis
Sep 05 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.114.1283754439.858.digitalmars-d puremagic.com...
 On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote:
 "SK" <sk metrokings.com> wrote in message
 news:mailman.113.1283750971.858.digitalmars-d 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.
Sep 06 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday 06 September 2010 01:53:55 Nick Sabalausky wrote:
 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.
I really have no idea why cmake doesn't ditch makefiles. It's probably because it's intended as a wrapper for a build system as opposed to being the build system itself, but I don't know. As for the documentation, I thought that it was extremely poor overall, so I got the book. They really should improve their documentation. - Jonathan M Davis
Sep 06 2010
prev sibling parent SK <sk metrokings.com> writes:
On Mon, Sep 6, 2010 at 1:53 AM, Nick Sabalausky <a a.a> wrote:
 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.114.1283754439.858.digitalmars-d 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
Sep 06 2010
prev sibling next sibling parent LMB <anonymous nowhere.com> writes:
Haven't tried it yet, but thank you very much! This is something I missed a lot
:-)

LMB

SK Wrote:

 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.
 
 Cheers,
 -steve
Sep 06 2010
prev sibling next sibling parent klickverbot <see klickverbot.at> writes:
Thanks a lot – I was just thinking about writing something like that 
myself when I stumbled over this post!

I have just switched to OS X, so I probably will be able to help you out 
in that regard.

I'll report back when I have found time to have a look on it.
Sep 06 2010
prev sibling next sibling parent Gareth Charnock <gareth.charnock gmail.com> writes:
I will definitely be checking this out. I've used CMake with C++ for 
quite a large project and it's been very good at of getting the done 
without being the infinite tower of turtles on turtles that autotools 
seems to be.

(I never managed to learn autotools so perhaps they don't seem as bad 
once you're using them.)

On 06/09/10 06:28, SK wrote:
 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.

 Cheers,
 -steve
Sep 06 2010
prev sibling next sibling parent reply "Gour D." <gour atmarama.net> writes:
On Sun, 5 Sep 2010 22:28:41 -0700
 "SK" =3D=3D SK <sk metrokings.com> wrote:
SK> Why labor over buggy Makefiles when you could be laboring over buggy SK> CMake files at a much more productive level of abstraction? :o) Do you recommend to learn & use CMake instead of using tools like Xfbuild (I'm interested for D project and, so far, was accustomed to Haskell's Cabal, so looking for similar experience.) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 08 2010
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-10-08 at 16:34 +0200, Gour D. wrote:

 Do you recommend to learn & use CMake instead of using tools like
 Xfbuild (I'm interested for D project and, so far, was accustomed to
 Haskell's Cabal, so looking for similar experience.)
For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy. I generally prefer SCons or Waf -- Waf is originally a fork of SCons but now is its own thing, and is aimed at being an Autotools replacement ("get source download and build on this machine" type model). SCons is better at handling the sort of situation I have: source repository shared by many platforms all needing builds in situ. Waf is somewhat faster than SCons. For my sins I am peripherally involved in the SCons development community, and I at some time elected myself as the maintainer of the D plugin -- the plugin as D shipped until recently with SCons assumed D 1.0 and I am only using D 2.0. So when I asked who could fix the problem, the answer came back "you can", so I did, sort of :-) It would be good if there was a community of D/SCons users so as to get some headway on making the SCons D plugin as good as it needs to be. Isn't Cabal a dependency resolution system rather than a build system? i.e. Cabal sits in the same sort of position as Apt, Ivy, the Maven dependency resolution system, rather than being the equivalent of Ant +Ivy or Maven as a whole. (C, C++, Fortran, and D seem to be less interested in depndency resolution than the JVM-based milieu of Java, Scala, Groovy, Clojure, etc. hence the Ant/Maven perspective.) I also tried starting a Haskell SCons plugin but haven't really got it moving properly as yet. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 08 2010
parent reply "Gour D." <gour atmarama.net> writes:
On Fri, 08 Oct 2010 17:26:25 +0100
 "Russel" =3D=3D Russel Winder <russel russel.org.uk> wrote:
Russel> For C, C++, Fortran, and hence D, I personally find CMake Russel> awkward and clumsy. =20 Hmm...based on what I know, CMake is universe for itself...not the most readable syntax etc., but it looks robust, capable of building large projects, cpack generating output in several formats, project files for different IDEs... Russel> I generally prefer SCons or Waf -- Waf is Russel> originally a fork of SCons but now is its own thing, and is Russel> aimed at being an Autotools replacement ("get source download Russel> and build on this machine" type model). =20 That's what we would like as well...although generating project files (e.g. for CodeBlock if others agree on common IDE across platforms) and/or generating package formats, installers...I bet that both waf & Scons do not support that? Russel> SCons is better at Russel> handling the sort of situation I have: source repository shared Russel> by many platforms all needing builds in situ. Waf is somewhat Russel> faster than SCons. =20 That makes it more attractive. Russel> For my sins I am peripherally involved in Russel> the SCons development community, and I at some time elected Russel> myself as the maintainer of the D plugin -- the plugin as D Russel> shipped until recently with SCons assumed D 1.0 and I am only Russel> using D 2.0. So when I asked who could fix the problem, the Russel> answer came back "you can", so I did, sort of :-) It would be Russel> good if there was a community of D/SCons users so as to get Russel> some headway on making the SCons D plugin as good as it needs Russel> to be. Am I right that there is support for D in waf as well? Russel> Isn't Cabal a dependency resolution system rather than a build Russel> system? i.e. Cabal sits in the same sort of position as Apt, Russel> Ivy, the Maven dependency resolution system, rather than being Russel> the equivalent of Ant +Ivy or Maven as a whole. (C, C++, Russel> Fortran, and D seem to be less interested in depndency Russel> resolution than the JVM-based milieu of Java, Scala, Groovy, Russel> Clojure, etc. hence the Ant/Maven perspective.) Well, Cabal stands for Common Architecture for Building Applications and Libraries so it is used for resolving deps, building the system and installing it (it can also build C-libs). So, we'll investigate a bit about CMake, waf... Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 08 2010
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-10-08 at 22:25 +0200, Gour D. wrote:
 On Fri, 08 Oct 2010 17:26:25 +0100
 "Russel" =3D=3D Russel Winder <russel russel.org.uk> wrote:
=20 Russel> For C, C++, Fortran, and hence D, I personally find CMake Russel> awkward and clumsy. =20 =20 Hmm...based on what I know, CMake is universe for itself...not the most readable syntax etc., but it looks robust, capable of building large projects, cpack generating output in several formats, project files for different IDEs...
I would go further and say the CMake build language is actually very poor -- from almost all aspects of cognition and comprehension. However, I am not going to get into SCons salesman mode or defender mode, nor start a "holy war" against CMake, I just wanted people to know that the choice is not between Make, Autotools and CMake, there is also SCons and Waf to name but two -- Ant, Maven, Gradle, etc are unlikely to be candidates in this arena since they are JVM focused and where there is support for C, C++, Fortran, it is actually quite poor. The real point is that you have to make up your mind what facilities you need in your context for your needs. There is no absolute total order that can be imposed on these things. Personally I am principally an Emacs and command line person so IDE is low on my agenda, though I use SCons as my build tool when using Eclipse/CDT. SCons has the capability if creating Visual Studio project files -- and we have to be honest here and say that most C and C++ coding happens in Visual Studio -- and whilst I don't think there is currently CodeBlock support it would be relatively easy to put it in place. I am fairly sure Waf has some facilities in this area. SCons and Waf are tarball and zipfile focused since between then they are the near monopoly format for distribution.
 Russel> I generally prefer SCons or Waf -- Waf is
 Russel> originally a fork of SCons but now is its own thing, and is
 Russel> aimed at being an Autotools replacement ("get source download
 Russel> and build on this machine" type model). =20
=20
 That's what we would like as well...although generating project files
 (e.g. for CodeBlock if others agree on common IDE across platforms)
 and/or generating package formats, installers...I bet that both waf &
 Scons do not support that?
See above, Visual Studio yes, Eclipse yes (by inference Netbeans possibly, IntelliJ IDEA possibly). CodeBlocks is a tiny minority IDE in the general scheme of things.
 Russel> SCons is better at
 Russel> handling the sort of situation I have: source repository shared
 Russel> by many platforms all needing builds in situ. Waf is somewhat
 Russel> faster than SCons. =20
=20
 That makes it more attractive.
=20
 Russel> For my sins I am peripherally involved in
 Russel> the SCons development community, and I at some time elected
 Russel> myself as the maintainer of the D plugin -- the plugin as D
 Russel> shipped until recently with SCons assumed D 1.0 and I am only
 Russel> using D 2.0.  So when I asked who could fix the problem, the
 Russel> answer came back "you can", so I did, sort of :-) It would be
 Russel> good if there was a community of D/SCons users so as to get
 Russel> some headway on making the SCons D plugin as good as it needs
 Russel> to be.
=20
 Am I right that there is support for D in waf as well?
Yes there is, it comes as standard. I think that like SCons, Waf deals with the DMD v2.0 vs. DMD v1.0 pain. The core problem is that v1.0 and v2.0 cannot be co-resident since they install all the same commands and yet the Phobos library has a different name in v2.0 than in v1.0.
 Russel> Isn't Cabal a dependency resolution system rather than a build
 Russel> system? i.e. Cabal sits in the same sort of position as Apt,
 Russel> Ivy, the Maven dependency resolution system, rather than being
 Russel> the equivalent of Ant +Ivy or Maven as a whole.  (C, C++,
 Russel> Fortran, and D seem to be less interested in depndency
 Russel> resolution than the JVM-based milieu of Java, Scala, Groovy,
 Russel> Clojure, etc. hence the Ant/Maven perspective.)
=20
 Well, Cabal stands for Common Architecture for Building Applications
 and Libraries so it is used for resolving deps, building the system
 and installing it (it can also build C-libs).
=20
 So, we'll investigate a bit about CMake, waf...
That is what needs to be done. 1. Don't believe things people tell you, find out for yourself; 2. Properly prioritize your needs to avoid featurist tick boxes driving your decision. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 09 2010
parent "Gour D." <gour atmarama.net> writes:
On Sat, 09 Oct 2010 10:19:50 +0100
 "Russel" =3D=3D Russel Winder wrote:
Russel> Personally I am principally an Emacs and command line person so Russel> IDE is low on my agenda, though I use SCons as my build tool Russel> when using Eclipse/CDT. SCons has the capability if creating Russel> Visual Studio project files -- and we have to be honest here Russel> and say that most C and C++ coding happens in Visual Studio -- Russel> and whilst I don't think there is currently CodeBlock support Russel> it would be relatively easy to put it in place. I am fairly Russel> sure Waf has some facilities in this area. I also use Emacs, but might use CodeBlocks if we the members of the team agree on it. There is plan to support creating Codeblock files in waf. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 09 2010
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
 Do you recommend to learn & use CMake instead of using tools like
 Xfbuild (I'm interested for D project and, so far, was accustomed to
 Haskell's Cabal, so looking for similar experience.)
For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy.
I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration. I never used this but CMake has generators for Visual Studio and through the Makefile Generators you can integrate it in CodeBlocks and Eclipse. Don't know how important this is. I live happily with the generated Makefiles. Coming back to the original question. I can recommend CMake especially if one plans to do C and C++ programming. For D we (Steve, Dean and I) are trying to improve the support. Fixing Mac OSX is next on my list.
 I generally prefer SCons or Waf -- Waf is originally a fork of
 SCons but now is its own thing, and is aimed at being an Autotools
 replacement ("get source download and build on this machine" type
 model).  SCons is better at handling the sort of situation I have:
 source repository shared by many platforms all needing builds in situ.
 Waf is somewhat faster than SCons.  For my sins I am peripherally
 involved in the SCons development community, and I at some time elected
 myself as the maintainer of the D plugin -- the plugin as D shipped
 until recently with SCons assumed D 1.0 and I am only using D 2.0.  So
 when I asked who could fix the problem, the answer came back "you can",
 so I did, sort of :-) It would be good if there was a community of
 D/SCons users so as to get some headway on making the SCons D plugin as
 good as it needs to be.
I have to admit I neither know Scons nor Waf. Maybe these are superior. They're Python-based, right? I'll guess that makes them favorable for Python programmers. On top of my head some things I find nice in CMake. Just curious whether Scons/Waf have similar features. * Find Google Test/other libraries (if supported) in one line: find_package(GTest REQUIRED) * Tight integration for testing and packaging (ctest, cpack) * Publishing build/test results * No dependencies besides a C++ compiler for installation. * Continuous Integration watching subversion repository * Valgrind/Purify integration Jens
Oct 08 2010
parent reply "Gour D." <gour atmarama.net> writes:
On Fri, 8 Oct 2010 21:41:55 +0200
 "Jens" =3D=3D Jens Mueller <jens.k.mueller gmx.de> wrote:
Jens> I also think CMake isn't that shiny. But you can get the job done Jens> once you're familiar with it. And it has been adopted by some big Jens> projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see Jens> http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). Jens> That should be put into consideration. Here is the waf list: http://code.google.com/p/waf/wiki/ProjectsUsingWaf Jens> I never used this but CMake has generators for Visual Studio and Jens> through the Makefile Generators you can integrate it in Jens> CodeBlocks and Eclipse. Don't know how important this is. I live Jens> happily with the generated Makefiles. in waf's TODO I found some similar items, although not labelled as high-priority: + IDE file generator (msvc, codeblocks) + CMake file interpreter Jens> Coming back to the original question. I can recommend CMake Jens> especially if one plans to do C and C++ programming. For D we Jens> (Steve, Dean and I) are trying to improve the support. Fixing Mac Jens> OSX is next on my list. My primary interest is D and developing on Linux, although we want our app to run on Mac & Windows as well (hopefully using QtD). Jens> I have to admit I neither know Scons nor Waf. Maybe these are Jens> superior. They're Python-based, right? I'll guess that makes them Jens> favorable for Python programmers. Waf really looks good and, afaics, it's more extensible than Scons. Here is the table with some comparisons: http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems Jens> On top of my head some things I find nice in CMake. Just curious Jens> whether Scons/Waf have similar features. I'm not at all familiar with waf, just read a bit about it and here is the feature list: http://code.google.com/p/waf/ and here is the 'book': http://freehackers.org/~tnagy/wafbook160p3/ Jens> * Find Google Test/other libraries (if supported) in one line: Jens> find_package(GTest REQUIRED) I see something like: ctx.find_program('touch', var=3D'TOUCH') Jens> * Tight integration for testing and packaging (ctest, cpack) Only dist for tarballs, afaict. Jens> * Publishing build/test results No idea. Jens> * No dependencies besides a C++ compiler for installation. This is one advantage of waf that it only requires ~80K python script which is, usually, distributed with the sources. Jens> * Continuous Integration watching subversion repository The above page says: "provides automatic rebuilds for continuous integration" =20 Jens> * Valgrind/Purify integration Considering Samba uses Waf, Google returned: http://wiki.samba.org/index.php/Debugging_individual_tests Moreover, since the system uses full-featured programming language, probably there are no restriction what can be done... In any case, it's interesting and we'll put it on our evaluation-list. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 08 2010
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2010-10-09 at 00:16 +0200, Gour D. wrote:
[ . . . ]
 Here is the waf list:
=20
 http://code.google.com/p/waf/wiki/ProjectsUsingWaf
The SCons list is at http://www.scons.org/wiki/SconsProjects but I think there are some big users who haven't signed up there. Intel for one who use SCons with their "huge modules" support system Parts that is a bolt on to SCons. So user lists are only as good as the marketing department of the product and Waf and SCons have none whilst Kitware does! [ . . . ]
 Waf really looks good and, afaics, it's more extensible than Scons.
I would put them both the same. The Waf plugin API is though a little more sophisticated.
 Here is the table with some comparisons:
=20
 http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems
One or two of those categories have been neatly crafted so as to ensure Waf comes out on top. Also sadly there are a number of error in the table, some boxes have a No in them where they should have a Yes. Also the table fails to mention Gradle. Moreover Ant is evolving and Maven 3 likewise so that Groovy (a dynamic programming language) can be used to replace XML at the front end, and used with Java and Scala to create plugins. The line that is serious though is the Dependencies line. Make uses timestamps which can mean incomplete builds or over building. Using hashes as Waf and SCons do means you always get the right about of work done. Both allow you to switch off the hashes and use timestamps (which are generally quicker) but CMake doesn't allow you to use hashes to get correct builds. This was the single biggest factor for the large companies that use Waf and SCons as they have 56hour builds and so minimizing the work done whilst ensuring correctness of the work done is critical. Hence hashes, hence Waf and SCons,.=20 [ . . . ]
=20
 Only dist for tarballs, afaict.
I thought Waf did zipfiles as well, SCons certainly does both. Is there a need for anything else beyond those?
 Jens> * Publishing build/test results
=20
 No idea.
Depends what is meant. If Waf and SCons don't have it then a few minutes and a Python plugin later you have the facility.
 Jens> * No dependencies besides a C++ compiler for installation.
=20
 This is one advantage of waf that it only requires ~80K python script
 which is, usually, distributed with the sources.
SCons can do the same but this is rarely done where it is the standard form for Waf. This shows the different philosophies behind Waf and SCons and consequently can be the deciding factor often. [ . . . ]
 In any case, it's interesting and we'll put it on our evaluation-list.
Happy evoluation :-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 09 2010
parent "Gour D." <gour atmarama.net> writes:
On Sat, 09 Oct 2010 10:56:45 +0100
 "Russel" =3D=3D Russel Winder wrote:
Russel> I thought Waf did zipfiles as well, SCons certainly does both. Correct. Default in Waf is bzip2, with the support for gzip & zip. Russel> Is there a need for anything else beyond those? Not really. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 09 2010
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour D. wrote:
 On Fri, 8 Oct 2010 21:41:55 +0200
 "Jens" == Jens Mueller <jens.k.mueller gmx.de> wrote:
Jens> Coming back to the original question. I can recommend CMake Jens> especially if one plans to do C and C++ programming. For D we Jens> (Steve, Dean and I) are trying to improve the support. Fixing Mac Jens> OSX is next on my list. My primary interest is D and developing on Linux, although we want our app to run on Mac & Windows as well (hopefully using QtD).
With CMake you can check whether Qt is installed on the system. There is a FindQt.cmake.
 Jens> I have to admit I neither know Scons nor Waf. Maybe these are
 Jens> superior. They're Python-based, right? I'll guess that makes them
 Jens> favorable for Python programmers.
 
 Waf really looks good and, afaics, it's more extensible than Scons.
 
 Here is the table with some comparisons:
 
 http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems
They have very good documentation. Something that's not the case for CMake. With CMake you have to google a lot. Thankfully that's mainly needed if you dive into into the internals. Writing a simple CMakeLists.txt is a matter of minutes. I hope I'm not too biased here because I've been using it for almost 2 years.
 Jens> On top of my head some things I find nice in CMake. Just curious
 Jens> whether Scons/Waf have similar features.
 
 I'm not at all familiar with waf, just read a bit about it and here is
 the feature list:
 
 http://code.google.com/p/waf/
 
 and here is the 'book':
 
 http://freehackers.org/~tnagy/wafbook160p3/
Wow. They have excellent documentation.
 Jens> * Find Google Test/other libraries (if supported) in one line:
 Jens>   find_package(GTest REQUIRED)
 
 I see something like:
 
 ctx.find_program('touch', var='TOUCH')
Only finds a program, right? I'd like to find a library. I.e. I need the path to the header files and the library files. I'll guess there is something like find_file.
 Jens> * Tight integration for testing and packaging (ctest, cpack)
 
 Only dist for tarballs, afaict.
I do not know how important this whole Windows integration is, but with CMake you can generate a Windows installer. Together with Visual Studio support it's a good choice if Windows is your main client. Could be the reason why CMake is used so often.
 Jens> * No dependencies besides a C++ compiler for installation.
 
 This is one advantage of waf that it only requires ~80K python script
 which is, usually, distributed with the sources.
You need to have python installed. I have no feeling how many system have python installed. But probably more than CMake.
 Jens> * Valgrind/Purify integration
 
 Considering Samba uses Waf, Google returned:
 
 http://wiki.samba.org/index.php/Debugging_individual_tests
Interesting.
 Moreover, since the system uses full-featured programming language,
 probably there are no restriction what can be done...
 
 In any case, it's interesting and we'll put it on our evaluation-list.
Can you keep me informed about the result? Just curious which features influenced your final decision. Jens
Oct 09 2010
parent "Gour D." <gour atmarama.net> writes:
On Sat, 9 Oct 2010 12:06:46 +0200
 "Jens" =3D=3D Jens Mueller wrote:
Jens> Wow. They have excellent documentation. Indeed. I'm just reading it. Jens> Only finds a program, right? I'd like to find a library. I.e. I Jens> need the path to the header files and the library files. I'll Jens> guess there is something like find_file. There is, e.g. ctx.find_file('fstab', ['/opt', '/etc']) Jens> I do not know how important this whole Windows integration is, Jens> but with CMake you can generate a Windows installer. That's missing in Waf. Jens> Together with Visual Studio support it's a good choice if Windows Jens> is your main client. Could be the reason why CMake is used so Jens> often. In my case, I'll develop on Linux. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 09 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2010-10-09 at 12:06 +0200, Jens Mueller wrote:
[ . . . ]
 With CMake you can check whether Qt is installed on the system. There is
 a FindQt.cmake.
Waf can do this sort of thing simply as well, especially via pgk-config if available. SCons is a little more clumsy but it is there and usable. Basically I think they are all the same on this sort of point in that there is a tick in the box. [ . . . ]
 They have very good documentation. Something that's not the case for
 CMake. With CMake you have to google a lot. Thankfully that's mainly
 needed if you dive into into the internals. Writing a simple
 CMakeLists.txt is a matter of minutes. I hope I'm not too biased here
 because I've been using it for almost 2 years.
I agree that just writing CMakeLists.txt is not hard if you have a straightforward project. But I found the poor documentation of CMake a barrier a couple of years back when I had a non-standard build. To be honest I don't think the Waf documentation is that good either. In far too many places presentation is Waf implementation oriented and assumes knowledge of the source code. SCons documentation is not that great either. The user guide is a bit too superficial, but the manual page is authoritative, just lacking in examples. The wikis and especially the mailing lists are the things that mean Waf and SCons users have few problems. =20 [ . . . ]
 ctx.find_program('touch', var=3D'TOUCH')
=20 Only finds a program, right? I'd like to find a library. I.e. I need the path to the header files and the library files. I'll guess there is something like find_file.
The giveaway is in the method name :-) there are also methods for checking for header files, libraries and packages. SCons is a bit behind Waf on this but it does have all the facilities. [ . . . ]
 I do not know how important this whole Windows integration is, but with
 CMake you can generate a Windows installer.
 Together with Visual Studio support it's a good choice if Windows is
 your main client. Could be the reason why CMake is used so often.
I suspect CMake is ahead of Waf and SCons on this, but there are external tools that can be use, and I am fairly sure they are usable trivially from Waf and SCons. [ . . . ]
 You need to have python installed. I have no feeling how many system
 have python installed. But probably more than CMake.
I suspect that Windows is the only system that does not now ship a version of Python as standard. [ . . . ]
 In any case, it's interesting and we'll put it on our evaluation-list.
=20 Can you keep me informed about the result? Just curious which features influenced your final decision.
I'd love to know as well. All too often people make decisions and the decision gets promulgated, but without the rationale for the decision. It is the decision+rationale that is so useful for future decision making. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 09 2010
parent reply "Gour D." <gour atmarama.net> writes:
On Sat, 09 Oct 2010 11:30:44 +0100
 "Russel" =3D=3D Russel Winder wrote:
Russel> > Can you keep me informed about the result? Just curious which Russel> > features influenced your final decision. Russel>=20 Russel> I'd love to know as well. All too often people make decisions Russel> and the decision gets promulgated, but without the rationale Russel> for the decision. It is the decision+rationale that is so Russel> useful for future decision making. OK. Based on that I've read & tried, I'm going to start with Waf. Rationale? a) I consider it's better investment of my time to become a little bit more familiar with Python in order to write Waf scripts (I'll have to tinker with e.g. Roundup tracker etc.) instead of learning another scripting language used in only one product. b) Missing features in Waf can be added considering there is complete programming language on disposal in comparison with limited and obscure language in CMake. c) although not up-to-date, but this benchmark (http://tinyurl.com/25do5ez) and some other reviews show that performance of Waf is quite decent in comparison with CMake and consider we won't write a new KDE, we consider it is enough for out purpose. d) Waf works on all the platforms we need, has normal support via mailing list, IRC and it is actively developed. e) it is, imho, more open-source project with decent documentation, iow. no need to google alot nor to buy (expensive) book to master it. f) there is out-of-the box support for D g) considering that Was is 'better' or 'fixed' Scons and projects like Samba are using it, we hope it will fulfill all our needs for a multi-platform GUI project in D. Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 09 2010
parent "Gour D." <gour atmarama.net> writes:
On Sat, 9 Oct 2010 16:48:15 +0200
 "Gour" =3D=3D "Gour D." <gour atmarama.net> wrote:
Gour> Rationale? I forgot to add: x) deps are determined by hash and not by timestamps Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 10 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote:
 Do you recommend to learn & use CMake instead of using tools like
 Xfbuild (I'm interested for D project and, so far, was accustomed to
 Haskell's Cabal, so looking for similar experience.)
=20 For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy.
=20 I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration.
Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. SCons is used by Intel for most of their software products, especially the parallel tools suite, also by id Games for all their products. Simply listing users of a product is a "pissing contest" and not at all helpful. If you choose a tool that many others have chosen and are happy with then fine, you get the comfort of not being on your own -- and that is a good thing. However, an individuals or organizations actual needs may mean that using something not chosen by the herd is far more beneficial. All these arguments happen when choosing version control systems as well as build systems.
 I never used this but CMake has generators for Visual Studio and through
 the Makefile Generators you can integrate it in CodeBlocks and Eclipse.
 Don't know how important this is. I live happily with the generated
 Makefiles.
SCons can likewise generate Visual Studio project files. SCons can be used directly in Eclipse so no need for Makefile generation.
 Coming back to the original question. I can recommend CMake especially
 if one plans to do C and C++ programming. For D we (Steve, Dean and I)
 are trying to improve the support. Fixing Mac OSX is next on my list.
I have no doubt that CMake is a viable alternative for some people/organizations in some contexts. As a replacement for Autotools, then compared to Waf it comes third for me behind second place SCons.
 I generally prefer SCons or Waf -- Waf is originally a fork of
 SCons but now is its own thing, and is aimed at being an Autotools
 replacement ("get source download and build on this machine" type
 model).  SCons is better at handling the sort of situation I have:
 source repository shared by many platforms all needing builds in situ.
 Waf is somewhat faster than SCons.  For my sins I am peripherally
 involved in the SCons development community, and I at some time elected
 myself as the maintainer of the D plugin -- the plugin as D shipped
 until recently with SCons assumed D 1.0 and I am only using D 2.0.  So
 when I asked who could fix the problem, the answer came back "you can",
 so I did, sort of :-) It would be good if there was a community of
 D/SCons users so as to get some headway on making the SCons D plugin as
 good as it needs to be.
=20 I have to admit I neither know Scons nor Waf. Maybe these are superior. They're Python-based, right? I'll guess that makes them favorable for Python programmers.
SCons and Waf are both Python systems that have an internal DSL for describing the build. Both have the classic two phase operation: read the files and build the DAG describing the project and build; analyse the filestore and spawn tasks in order to reconcile the actual filestore with the required filestore. (Actually 'filestore' is a variable here, you an target things other than the filestore, but its usually the filestore being processed.) Using Python (or any other dynamic language I would suspect, cf Rake, Rant using Ruby) is a big win, certainly over m4 macros. CMake has its own language which is part way to being Lisp but has lots of quirks and idiosyncrasies such that if they had just used a Lisp interpreter, things would be a lot better.
 On top of my head some things I find nice in CMake. Just curious whether
 Scons/Waf have similar features.
 * Find Google Test/other libraries (if supported) in one line:
   find_package(GTest REQUIRED)
Waf and SCons can both do this but it is not packaged as a one liner in this form. The issue is how the dependencies are packaged up in order to create. CMake has one route, Waf one route and SCons a slightly different route. CMake looks good on this point but Waf and SCons are not poor in comparison.
 * Tight integration for testing and packaging (ctest, cpack)
Somewhat unfair to appear to name CTest and CPack as requirements as they are are Kitware products integrated into CMake ;-) Waf and SCons both have infrastructure for supporting tests, they are just called something different than CTest and CPack
 * Publishing build/test results
Isn't that the job of the continuous integration server?
 * No dependencies besides a C++ compiler for installation.
CMake requires cmake, make, bash, etc. in addition to the compilation tool chain which is usually more than just the compiler. Waf and SCons both require a Python installation, but that is increasingly standard now. No need for Bash or Make, but you do need exactly the same toolchain otherwise.
 * Continuous Integration watching subversion repository
Why Subversion explicitly, it is so last century :-) Bazaar, Mercurial and Git are the "go to" version control systems these days. Even if you have a Subversion central repository, you use Bazaar, Mercurial or Git as your client. Well I do anyway! Actually I am not sure what you mean by this. CI is usually these days either Buildbot or Hudson
 * Valgrind/Purify integration
I believe both have this but I don't know, in my C++ programming I never use these tools. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 09 2010
parent reply klickverbot <see klickverbot.at> writes:
On 10/9/10 11:40 AM, Russel Winder wrote:
 Well KDE was about to choose bksys (the immediate ancestor of Waf) until
 some nasty politiking went on and all of a sudden they chose CMake.  I
 don't know all the details, but I know enough to say that that decision
 was not made based on a proper study.
If you accuse someone of not basing the decision »on a proper study«, I am sure you have some references on hand for that? Usually, a lot of decisions regarding KDE is made based on a meritocracy-like system, »nasty politiking« isn't something I'd expect to see very often… This article[1] from the KDE build system maintainer paints quite a different picture. It seems that they indeed tried to use SCons, even actively worked at the SCons extension bksys (as in »Build Kde System«). Apparently, however, a number of not quite easily resolvable problems popped up (including missing support by the SCons upstream), so they ditched SCons/bksys and went with CMake. Later on, somebody decided to do a complete rewrite of bksys/SCons, because some of the problems were apparently related so closely to the internals of SCons that there was no other feasible way of fixing them. I agree that the macro language of CMake is probably not the most beautiful solution (a port to Lua is planned, IIRC), but it has been proven to work almost flawlessly on huge projects. Even for the build system cracks of the KDE project, autotools was a constant source of trouble back when they used it – CMake apparently has solved most of the problems, while SCons/bksys failed at it. [1] http://lwn.net/Articles/188693/
Oct 09 2010
parent Russel Winder <russel russel.org.uk> writes:
On Sat, 2010-10-09 at 13:01 +0200, klickverbot wrote:

 If you accuse someone of not basing the decision =C2=BBon a proper study=
=C2=AB, I=20
 am sure you have some references on hand for that? Usually, a lot of=20
 decisions regarding KDE is made based on a meritocracy-like system,=20
 =C2=BBnasty politiking=C2=AB isn't something I'd expect to see very often=
=E2=80=A6 Personal communication with the parties involved and being in on various email exchanges about the whole thing, some of which can be found on the SCons and KDE mailing list archives.
 This article[1] from the KDE build system maintainer paints quite a=20
 different picture. It seems that they indeed tried to use SCons, even=20
 actively worked at the SCons extension bksys (as in =C2=BBBuild Kde Syste=
m=C2=AB).=20
 Apparently, however, a number of not quite easily resolvable problems=20
 popped up (including missing support by the SCons upstream), so they=20
 ditched SCons/bksys and went with CMake.
The article paints something of a rosy picture on the incident, and I find it a bit disingenuous to try and shift blame to the SCons developers when actually it was more complicated than that. If we want to go into details we can but I think not on this email list.
 Later on, somebody decided to do a complete rewrite of bksys/SCons,=20
 because some of the problems were apparently related so closely to the=20
 internals of SCons that there was no other feasible way of fixing them.
In some ways this is a very true statement, but this shouldn't taken as "SCons is rubbish". There are crucial differences in the way Waf and SCons work which mean both are right in their own way. Having said this there are a couple of classes in the SCons implementation that need to be totally rewritten.
 I agree that the macro language of CMake is probably not the most=20
 beautiful solution (a port to Lua is planned, IIRC), but it has been=20
 proven to work almost flawlessly on huge projects. Even for the build=20
 system cracks of the KDE project, autotools was a constant source of=20
 trouble back when they used it =E2=80=93 CMake apparently has solved most=
of the=20
 problems, while SCons/bksys failed at it.
Clearly CMake works fine now for KDE. This is good. However I take issue with the sentiment of the last phrase. You imply that CMake works and SCons doesn't (overstating things a bit I guess, but . . . ), I think that it is not reasonable to make this inference. If the bksys route had been followed up as the CMake one was at the time I am certain that it would be working as well today for KDE. But that is speculation since there can be no actual data now. Again, we can go over this if you want, but I suggest not on this email list. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 09 2010
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Russel Winder wrote:
 On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote:
 For C, C++, Fortran, and hence D, I personally find CMake awkward and
 clumsy.
I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration.
Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. SCons is used by Intel for most of their software products, especially the parallel tools suite, also by id Games for all their products. Simply listing users of a product is a "pissing contest" and not at all helpful. If you choose a tool that many others have chosen and are happy with then fine, you get the comfort of not being on your own -- and that is a good thing. However, an individuals or organizations actual needs may mean that using something not chosen by the herd is far more beneficial.
My point is only that CMake works for big projects. Which makes a strong argument. If you run into a problem you can very likely check out how they did it. However they ended up with it, it seems to do its job. But of course if other tools can handle this equally good you need to go beyond that.
 I never used this but CMake has generators for Visual Studio and through
 the Makefile Generators you can integrate it in CodeBlocks and Eclipse.
 Don't know how important this is. I live happily with the generated
 Makefiles.
SCons can likewise generate Visual Studio project files. SCons can be used directly in Eclipse so no need for Makefile generation.
That's nice.
 I have to admit I neither know Scons nor Waf. Maybe these are superior.
 They're Python-based, right? I'll guess that makes them favorable for
 Python programmers.
SCons and Waf are both Python systems that have an internal DSL for describing the build. Both have the classic two phase operation: read the files and build the DAG describing the project and build; analyse the filestore and spawn tasks in order to reconcile the actual filestore with the required filestore. (Actually 'filestore' is a variable here, you an target things other than the filestore, but its usually the filestore being processed.) Using Python (or any other dynamic language I would suspect, cf Rake, Rant using Ruby) is a big win, certainly over m4 macros. CMake has its own language which is part way to being Lisp but has lots of quirks and idiosyncrasies such that if they had just used a Lisp interpreter, things would be a lot better.
I agree. It's not a nice solution. Maybe they are just known because a company supports it and puts some effort into it. But in the long run maybe others will take over because of better design.
 On top of my head some things I find nice in CMake. Just curious whether
 Scons/Waf have similar features.
 * Find Google Test/other libraries (if supported) in one line:
   find_package(GTest REQUIRED)
Waf and SCons can both do this but it is not packaged as a one liner in this form. The issue is how the dependencies are packaged up in order to create. CMake has one route, Waf one route and SCons a slightly different route. CMake looks good on this point but Waf and SCons are not poor in comparison.
How do you do this with Waf/Scons? Best solution to me is: Somebody writes a module for finding a library and this module is distributed with the tool. The user only needs to include the module.
 * Tight integration for testing and packaging (ctest, cpack)
Somewhat unfair to appear to name CTest and CPack as requirements as they are are Kitware products integrated into CMake ;-) Waf and SCons both have infrastructure for supporting tests, they are just called something different than CTest and CPack
Just wanted to mention that you can test and package your software. I'm not here to disqualify any other tool. Just want to say what you can do with CMake and what seems important to me.
 * Publishing build/test results
Isn't that the job of the continuous integration server?
Depends. I know of a C++ project that uses CMake. Before they ship a new release they need to make sure that the building and testing pass. On their mailing list the maintainer announces that she likes to ship a new version and says something like: We want to support these compilers and those platforms. Since each developer has a different development setup they just run the tests locally and publish them to a central board. One after the other the developers post their results. I find this quite nice for distributed/Open Source development. Decoupling the testing and publishing. Of course you can setup your own machine that tests all of these different configurations. With Hudson it seems to me that there is one central point that does the integration. Maybe they allow some distribution. Just wanted to point out that I find this separation/distribution useful.
 * No dependencies besides a C++ compiler for installation.
CMake requires cmake, make, bash, etc. in addition to the compilation tool chain which is usually more than just the compiler.
Oh yes. You're absolutely right. I forgot to think about those because they are usually there. I shouldn't take them for granted.
 Waf and SCons both require a Python installation, but that is
 increasingly standard now.  No need for Bash or Make, but you do need
 exactly the same toolchain otherwise.
Right.
 * Continuous Integration watching subversion repository
Why Subversion explicitly, it is so last century :-) Bazaar, Mercurial and Git are the "go to" version control systems these days. Even if you have a Subversion central repository, you use Bazaar, Mercurial or Git as your client. Well I do anyway! Actually I am not sure what you mean by this. CI is usually these days either Buildbot or Hudson
I think the new century version control systems are supported as well. Don't know to what extent though. What is CI in the end. It's get me that the software out of the repository and build/test it and publish results. I would break this into (at least) two steps building/testing and publishing. For example I tend to forget running the tests before committing. So I set it up to watch my personal repository. It does building and testing for me but does not publish the results. If it fails it can give me some local feedback. This way I automatically make sure that I broke nothing. As I said that's something I tend to forget. To sum up I'm arguing for having some kind of local integration. And Hudson is nothing like some special kind of this. I mean I could setup a local Hudson. But isn't it nice to have all what's needed coming with the sources. Everybody can do the integration for their system configuration(s) himself. See for example http://my.cdash.org/index.php?project=libarchive http://my.cdash.org/index.php?project=Teem http://my.cdash.org/index.php?project=CTK&display=project
 * Valgrind/Purify integration
I believe both have this but I don't know, in my C++ programming I never use these tools.
Seems so. Jens
Oct 09 2010
prev sibling parent SK <sk metrokings.com> writes:
On Fri, Oct 8, 2010 at 12:41 PM, Jens Mueller <jens.k.mueller gmx.de> wrote:
 I also think CMake isn't that shiny. But you can get the job done once
 you're familiar with it.
My sentiments exactly. Discussing the beauties of a particular build system is all well and good, but what really matters are the warts that emerge only after you're a long way into a big project.
Oct 10 2010
prev sibling parent reply Gour <gour atmarama.net> writes:
On Sun, 5 Sep 2010 22:28:41 -0700
SK <sk metrokings.com> wrote:

 Why labor over buggy Makefiles when you could be laboring over buggy
 CMake files at a much more productive level of abstraction?  :o)
I played with Waf a bit and it has nice support for D. However, despite many contributors listed, it still seems to be mostly one-man-show which makes me a bit reluctant to use it over Cmake (SCons seems to be very slow without much progress), so I wonder what is the current status of the project? Any hope that D support will be applied in upstream? What about 64bit support in dmd2? Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 21 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-02-21 at 11:31 +0100, Gour wrote:
[ . . . ]
=20
 I played with Waf a bit and it has nice support for D.
=20
 However, despite many contributors listed, it still seems to be mostly
 one-man-show which makes me a bit reluctant to use it over Cmake
 (SCons seems to be very slow without much progress), so I wonder what
 is the current status of the project?
SCons core development does appear to be in a bit of hiatus just now, but this happens from time to time. The project has always picked up again though.=20
 Any hope that D support will be applied in upstream?
=20
 What about 64bit support in dmd2?
Are you talking about CMake or SCons here? For SCons, I have "forked" the D tool in the SCons core to be a separate project, cf. https://bitbucket.org/russel/scons_dmd_new --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 21 2011
parent Gour <gour atmarama.net> writes:
On Mon, 21 Feb 2011 10:56:50 +0000
Russel Winder <russel russel.org.uk> wrote:

=20
 Any hope that D support will be applied in upstream?
=20
 What about 64bit support in dmd2?
=20 Are you talking about CMake or SCons here?
CMake.
 For SCons, I have "forked" the D tool in the SCons core to be a
 separate project, cf. https://bitbucket.org/russel/scons_dmd_new
I may take a look, although CMake seems to be secure project. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 21 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Sun, 5 Sep 2010 22:28:41 -0700
 SK <sk metrokings.com> wrote:
 
 Why labor over buggy Makefiles when you could be laboring over buggy
 CMake files at a much more productive level of abstraction?  :o)
I played with Waf a bit and it has nice support for D. However, despite many contributors listed, it still seems to be mostly one-man-show which makes me a bit reluctant to use it over Cmake (SCons seems to be very slow without much progress), so I wonder what is the current status of the project? Any hope that D support will be applied in upstream?
I don't know about upstreaming it. Certainly it would be nice. But for doing so I need polish it further. It seems that not many people are using CMakeD and there seems to be less interest in it. But I used it for a word cloud I programed for a course (see here http://gitorious.org/wordcloud). The nice thing is that you can rely on CMake's modules. E.g. in the above example it was straightforward to let CMake make sure that the GD library it installed. That makes it very useful for integrating a C/C++ library. If you do not know already, the getting started guide is here http://code.google.com/p/cmaked2/wiki/GettingStarted According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu with CMake at least 2.8.2 and dmd at least 2.049. It should work on Windows as well. Some people have used it. Recently I added gdc support which works for me. But so far I haven't got any feedback from other users.
 What about 64bit support in dmd2?
You mean support for building 64bit code with dmd2 using CMakeD? That should be fairly straightforward given that you just need to pass -m64 to dmd. I think by default it builds 32-bit even on a 64-bit machine. But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you. Recently I've been a bit distracted from CMakeD development since I stumbled over Gyp http://code.google.com/p/gyp/ and Premake http://industriousone.com/premake Both address similar needs like CMake but do not support D yet. Jens
Feb 21 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 21 Feb 2011 12:40:11 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 I don't know about upstreaming it. Certainly it would be nice. But for
 doing so I need polish it further.
OK.
 It seems that not many people are using CMakeD and there seems to be
 less interest in it.=20
I believe many are waiting that D(2) become consolidated a bit, 64bit port etc. At least, I'm the one of them. :-)
 But I assume this is going to change once 64-bit is stable.
 If I find some time I will build the above word cloud example for
 64-bit and report here, if that helps you.
I'll take a look tomorrow closer look at CMakeD.
 Recently I've been a bit distracted from CMakeD development since I
 stumbled over
 Gyp
 http://code.google.com/p/gyp/
 and
 Premake
 http://industriousone.com/premake
 Both address similar needs like CMake but do not support D yet.
They look interesting, but I'm sure they cannot replace CMake and therefore hope D will become 1st class citizen in the CMake country. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 21 2011
parent Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Mon, 21 Feb 2011 12:40:11 +0100
 Jens Mueller <jens.k.mueller gmx.de> wrote:
 
 Recently I've been a bit distracted from CMakeD development since I
 stumbled over
 Gyp
 http://code.google.com/p/gyp/
 and
 Premake
 http://industriousone.com/premake
 Both address similar needs like CMake but do not support D yet.
They look interesting, but I'm sure they cannot replace CMake and therefore hope D will become 1st class citizen in the CMake country.
Very true. CMake is used widely and has built-in support for finding different often used library like Boost, SDL, OpenSSL, ... So if you need to use these library CMake is a good candidate. Jens
Feb 22 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote:
[ . . . ]
 I don't know about upstreaming it. Certainly it would be nice. But for
 doing so I need polish it further.
Can the code comprising the D support for CMake be "packaged" up so that it can be offerred to everyone direct from a DVCS repository? SCons and Waf have the tool concept to allow for this. CMake must have something analogous. People can then make use of the D support with their CMake without the necessity of it heading upstream -- though it would be good for that to happen eventually.
 It seems that not many people are using CMakeD and there seems to be
 less interest in it. But I used it for a word cloud I programed for a
 course (see here http://gitorious.org/wordcloud). The nice thing is that
 you can rely on CMake's modules. E.g. in the above example it was
 straightforward to let CMake make sure that the GD library it installed.
 That makes it very useful for integrating a C/C++ library.
 If you do not know already, the getting started guide is here
 http://code.google.com/p/cmaked2/wiki/GettingStarted
 According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it
 was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu
 with CMake at least 2.8.2 and dmd at least 2.049. It should work on
 Windows as well. Some people have used it.
 Recently I added gdc support which works for me. But so far I haven't
 got any feedback from other users.
Personally I prefer SCons and Waf over CMake, but would be happy to trial CMake and its D support. In fact the SCons tool I am trying to force myself to work on and the CMake D support may help each other by collaborating. =20
 What about 64bit support in dmd2?
=20 You mean support for building 64bit code with dmd2 using CMakeD? That should be fairly straightforward given that you just need to pass -m64 to dmd. I think by default it builds 32-bit even on a 64-bit machine. But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you.
In one sense it is as easy as passing -m64 but there is also the issue of the list of libraries needed at link time -- or does the CMake stuff already pull in that information from dmd.conf?
 Recently I've been a bit distracted from CMakeD development since I
 stumbled over
 Gyp
 http://code.google.com/p/gyp/
 and
 Premake
 http://industriousone.com/premake
 Both address similar needs like CMake but do not support D yet.
Are these good enough to get traction compared to SCons, Waf, CMake, Autotools, Make, Ant, Maven, Gradle, Gant? This is a serious question not a troll. There is always space for a new, better build framework to take the community by storm, but on the other hand if they are just side shows then it dilutes effort and progress.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 21 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Russel Winder wrote:
 On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote:
 [ . . . ]
 I don't know about upstreaming it. Certainly it would be nice. But for
 doing so I need polish it further.
Can the code comprising the D support for CMake be "packaged" up so that it can be offerred to everyone direct from a DVCS repository? SCons and Waf have the tool concept to allow for this. CMake must have something analogous. People can then make use of the D support with their CMake without the necessity of it heading upstream -- though it would be good for that to happen eventually.
Don't know how packaging is done in SCons/Waf. With CMakeD, you clone the repository, i.e. $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2 and $ cd cmaked2/cmaked $ mkdir build $ cd build $ cmake .. $ make install to install it. That will copy the necessary files into your CMake installation. I'll guess SCons/Waf offers something more than that.
 It seems that not many people are using CMakeD and there seems to be
 less interest in it. But I used it for a word cloud I programed for a
 course (see here http://gitorious.org/wordcloud). The nice thing is that
 you can rely on CMake's modules. E.g. in the above example it was
 straightforward to let CMake make sure that the GD library it installed.
 That makes it very useful for integrating a C/C++ library.
 If you do not know already, the getting started guide is here
 http://code.google.com/p/cmaked2/wiki/GettingStarted
 According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it
 was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu
 with CMake at least 2.8.2 and dmd at least 2.049. It should work on
 Windows as well. Some people have used it.
 Recently I added gdc support which works for me. But so far I haven't
 got any feedback from other users.
Personally I prefer SCons and Waf over CMake, but would be happy to trial CMake and its D support. In fact the SCons tool I am trying to force myself to work on and the CMake D support may help each other by collaborating.
Yeah. I try to help, if I can. Don't hesitate asking. Though I have to admit I have almost no Python skills. I like Ruby more. It pleases my eyes and there seems to be only enough space for one scripting language in my head.
 What about 64bit support in dmd2?
You mean support for building 64bit code with dmd2 using CMakeD? That should be fairly straightforward given that you just need to pass -m64 to dmd. I think by default it builds 32-bit even on a 64-bit machine. But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you.
In one sense it is as easy as passing -m64 but there is also the issue of the list of libraries needed at link time -- or does the CMake stuff already pull in that information from dmd.conf?
CMakeD just relies on dmd. But you're right it's a bit more complicated. It seems that on Linux CMake has no proper way of cross building a 32 bit/64 bit version. That kind of cross compiling does not seems to work. I would need to investigate further to find out whether it's a dmd problem. Usually I think for building a 32 bit C binary you just pass -m32 then the linker should search in ...lib32/. If you build a 64 bit binary it should search in ...lib64/. If you don't specify anything it's up to the compiler. CMake's task is just to check whether the dependent library is installed. I think at the moment it does not look in lib32/lib64 separately. In that sense it's support for cross compiling is weak. I may be wrong here.
 Recently I've been a bit distracted from CMakeD development since I
 stumbled over
 Gyp
 http://code.google.com/p/gyp/
 and
 Premake
 http://industriousone.com/premake
 Both address similar needs like CMake but do not support D yet.
Are these good enough to get traction compared to SCons, Waf, CMake, Autotools, Make, Ant, Maven, Gradle, Gant? This is a serious question not a troll. There is always space for a new, better build framework to take the community by storm, but on the other hand if they are just side shows then it dilutes effort and progress.
I do not know yet. I think both of them are pretty weak regarding already available modules, i.e. files to find a specific dependency. Gyp is developed for building Chromium. They had a problem with SCons while migrating to it. They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake I like premake for it's readability see http://industriousone.com/sample-script and it's all Lua. Though I'm not sure whether I can keep two scripting languages in my head. But Lua seems to be very simple. Jens
Feb 21 2011
next sibling parent reply Gour <gour atmarama.net> writes:
On Mon, 21 Feb 2011 21:22:54 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 With CMakeD, you clone the repository, i.e.
 $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
 and
 $ cd cmaked2/cmaked
 $ mkdir build
 $ cd build
 $ cmake ..
 $ make install
=20
 to install it. That will copy the necessary files into your CMake
 installation.
I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: [gour atmarama tests] make Scanning dependencies of target lib_1 [ 10%] Building D object lib_1/CMakeFiles/lib_1.dir/lib_1.o Linking D static library liblib_1.a [ 10%] Built target lib_1 Scanning dependencies of target lib_2 [ 20%] Building C object lib_2/CMakeFiles/lib_2.dir/lib_2.o Linking C static library liblib_2.a [ 20%] Built target lib_2 Scanning dependencies of target app_1 [ 30%] Building D object app_1/CMakeFiles/app_1.dir/app_1.o Linking D executable app_1 [ 30%] Built target app_1 Scanning dependencies of target app_2 [ 40%] Building D object app_2/CMakeFiles/app_2.dir/app_2.o Linking D executable app_2 [ 40%] Built target app_2 Scanning dependencies of target app_3 [ 50%] Building D object app_3/CMakeFiles/app_3.dir/app_3.o Linking D executable app_3 [ 50%] Built target app_3 Scanning dependencies of target app_5 [ 60%] Building D object app_5/CMakeFiles/app_5.dir/app_5.o [ 70%] Building C object app_5/CMakeFiles/app_5.dir/cfunc.o Linking D executable app_5 [ 70%] Built target app_5 Scanning dependencies of target app_4 [ 80%] Building D object app_4/CMakeFiles/app_4.dir/app_4.o Linking D executable app_4 [ 80%] Built target app_4 Scanning dependencies of target app_6 [ 90%] Building D object app_6/CMakeFiles/app_6.dir/app_6.o Linking D executable app_6 [ 90%] Built target app_6 Scanning dependencies of target app_7 [100%] Building D object app_7/CMakeFiles/app_7.dir/app_7.o std.perf has been scheduled for deprecation. Please use std.datetime instead. Linking D executable app_7 [100%] Built target app_7 Is it OK?
 I do not know yet. I think both of them are pretty weak regarding
 already available modules, i.e. files to find a specific dependency.
 Gyp is developed for building Chromium. They had a problem with SCons
 while migrating to it.
 They also wrote in what regard CMake didn't work out for them
 http://code.google.com/p/gyp/wiki/GypVsCMake
Do you have any issue with CMake that it does not work for you? Considering that KDE is (still) using it, I assume that, despite its possible awkwardness, it must be quite robust build system.
 I like premake for it's readability see
 http://industriousone.com/sample-script and it's all Lua. Though I'm
 not sure whether I can keep two scripting languages in my head. But
 Lua seems to be very simple.
I consider to maybe use Lua as scripting DSL in our app...we'll see...it's still too early to say...so, yes, it is cute language, but premake then resembles Waf with the exception of using Python instead. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
next sibling parent reply Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 09:42:46 +0100
Gour <gour atmarama.net> wrote:

 I installed CMakeD from the archlinux package, then pulled from the
 repo and tried tests suite. Here is the result:
Oops...forgot to run 'make test': [gour atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleB.d Start 9: moduleA.d 100% tests passed, 0 tests failed out of 9 Total Test time (real) =3D 0.28 sec So, everything is fine on x86_64 (however, still using 32bit dmd2 waiting for new package). Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Tue, 22 Feb 2011 09:42:46 +0100
 Gour <gour atmarama.net> wrote:
 
 I installed CMakeD from the archlinux package, then pulled from the
 repo and tried tests suite. Here is the result:
Oops...forgot to run 'make test': [gour atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleB.d Start 9: moduleA.d 100% tests passed, 0 tests failed out of 9 Total Test time (real) = 0.28 sec So, everything is fine on x86_64 (however, still using 32bit dmd2 waiting for new package).
Yeah. That looks good. I'd like to add your setup to http://code.google.com/p/cmaked2/wiki/TestedPlatforms Can please you leave a comment there? I will try adding -m64 flag and see how it goes. Jens
Feb 22 2011
parent Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 12:10:08 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 Yeah. That looks good. I'd like to add your setup to
 http://code.google.com/p/cmaked2/wiki/TestedPlatforms
 Can please you leave a comment there?
Done. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Tue, 22 Feb 2011 09:42:46 +0100
 Gour <gour atmarama.net> wrote:
 
 I installed CMakeD from the archlinux package, then pulled from the
 repo and tried tests suite. Here is the result:
Oops...forgot to run 'make test': [gour atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleB.d Start 9: moduleA.d 100% tests passed, 0 tests failed out of 9 Total Test time (real) = 0.28 sec So, everything is fine on x86_64 (however, still using 32bit dmd2 waiting for new package).
If you want a 64-bit build. Change in tests/CMakeLists.txt the lines SET( GLOBAL_DMD_DEFS "-w -wi" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m32" ) to SET( GLOBAL_DMD_DEFS "-w -wi -m64" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" ) I just did this. $ file app_1/app_1 app_1/app_1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped But something is wrong with app7 on amd64. $ make test Running tests... Test project /home/jkm/local/build/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleA.d Start 9: moduleB.d 89% tests passed, 1 tests failed out of 9 Total Test time (real) = 0.30 sec The following tests FAILED: 7 - app_7 (SEGFAULT) Errors while running CTest make: *** [test] Error 8 Somebody used CMakeD successfully with gdc and even there app_7 segfaulted. So it appears to be a problem in app_7. If you comment out the timing code it works. I will look later into this. Jens
Feb 22 2011
prev sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jens Mueller wrote:
 Gour wrote:
 On Tue, 22 Feb 2011 09:42:46 +0100
 Gour <gour atmarama.net> wrote:
 
 I installed CMakeD from the archlinux package, then pulled from the
 repo and tried tests suite. Here is the result:
Oops...forgot to run 'make test': [gour atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleB.d Start 9: moduleA.d 100% tests passed, 0 tests failed out of 9 Total Test time (real) = 0.28 sec So, everything is fine on x86_64 (however, still using 32bit dmd2 waiting for new package).
If you want a 64-bit build. Change in tests/CMakeLists.txt the lines SET( GLOBAL_DMD_DEFS "-w -wi" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m32" ) to SET( GLOBAL_DMD_DEFS "-w -wi -m64" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" ) I just did this. $ file app_1/app_1 app_1/app_1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped But something is wrong with app7 on amd64. $ make test Running tests... Test project /home/jkm/local/build/cmaked2/tests/build Start 1: app_1 Start 2: app_2 Start 3: app_3 Start 4: app_5 Start 5: app_4 Start 6: app_6 Start 7: app_7 Start 8: moduleA.d Start 9: moduleB.d 89% tests passed, 1 tests failed out of 9 Total Test time (real) = 0.30 sec The following tests FAILED: 7 - app_7 (SEGFAULT) Errors while running CTest make: *** [test] Error 8 Somebody used CMakeD successfully with gdc and even there app_7 segfaulted. So it appears to be a problem in app_7. If you comment out the timing code it works. I will look later into this.
I changed the timing code within app7 to use StopWatch. It now works. But there are some hacks in CMakeD's test examples. In lib_2/CMakeLists.txt app_5/CMakeLists.txt the -m32 was pretty hard coded. For building 64 bit it should be now sufficient to set SET( GLOBAL_DMD_DEFS "-w -wi -m64" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" ) For 32 Bit SET( GLOBAL_DMD_DEFS "-w -wi" ) SET( GLOBAL_GCC_DEFS "-Wall -pedantic" ) the way it is set right now should work. But remember that you need to specify -m32 if you want to use the C linker. Because at least with gcc on x86-64 it defaults to link 64-bit code. That's why the -m32 is optional for dmd since this seems to be the default. But as said earlier this will very likely change once 64-bit is stable. I pushed the changes to google code. Have a try. Jens
Feb 22 2011
prev sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Mon, 21 Feb 2011 21:22:54 +0100
 Jens Mueller <jens.k.mueller gmx.de> wrote:
 
 With CMakeD, you clone the repository, i.e.
 $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
 and
 $ cd cmaked2/cmaked
 $ mkdir build
 $ cd build
 $ cmake ..
 $ make install
 
 to install it. That will copy the necessary files into your CMake
 installation.
I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: [gour atmarama tests] make Scanning dependencies of target lib_1 [ 10%] Building D object lib_1/CMakeFiles/lib_1.dir/lib_1.o Linking D static library liblib_1.a [ 10%] Built target lib_1 Scanning dependencies of target lib_2 [ 20%] Building C object lib_2/CMakeFiles/lib_2.dir/lib_2.o Linking C static library liblib_2.a [ 20%] Built target lib_2 Scanning dependencies of target app_1 [ 30%] Building D object app_1/CMakeFiles/app_1.dir/app_1.o Linking D executable app_1 [ 30%] Built target app_1 Scanning dependencies of target app_2 [ 40%] Building D object app_2/CMakeFiles/app_2.dir/app_2.o Linking D executable app_2 [ 40%] Built target app_2 Scanning dependencies of target app_3 [ 50%] Building D object app_3/CMakeFiles/app_3.dir/app_3.o Linking D executable app_3 [ 50%] Built target app_3 Scanning dependencies of target app_5 [ 60%] Building D object app_5/CMakeFiles/app_5.dir/app_5.o [ 70%] Building C object app_5/CMakeFiles/app_5.dir/cfunc.o Linking D executable app_5 [ 70%] Built target app_5 Scanning dependencies of target app_4 [ 80%] Building D object app_4/CMakeFiles/app_4.dir/app_4.o Linking D executable app_4 [ 80%] Built target app_4 Scanning dependencies of target app_6 [ 90%] Building D object app_6/CMakeFiles/app_6.dir/app_6.o Linking D executable app_6 [ 90%] Built target app_6 Scanning dependencies of target app_7 [100%] Building D object app_7/CMakeFiles/app_7.dir/app_7.o std.perf has been scheduled for deprecation. Please use std.datetime instead. Linking D executable app_7 [100%] Built target app_7 Is it OK?
That looks good.
 I do not know yet. I think both of them are pretty weak regarding
 already available modules, i.e. files to find a specific dependency.
 Gyp is developed for building Chromium. They had a problem with SCons
 while migrating to it.
 They also wrote in what regard CMake didn't work out for them
 http://code.google.com/p/gyp/wiki/GypVsCMake
Do you have any issue with CMake that it does not work for you?
It does work for me most of the time. I work on Linux. There is one neat trick if you need to link against shared libraries which isn't supported by dmd yet. For these cases I rely on gcc. E.g. add_executable(myDExecutable src.d) set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C) target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES}) will link myDExecutable against libraries mentioned in CMAKE_REQUIRED_LIBRARIES.
 Considering that KDE is (still) using it, I assume that, despite its
 possible awkwardness, it must be quite robust build system.
Yeah. I'll guess though. But since it has it's own language some things are really annoying to do. I think the newer systems are better in that regard. They give you a nicer syntax and usually a full blown scripting language.
 I like premake for it's readability see
 http://industriousone.com/sample-script and it's all Lua. Though I'm
 not sure whether I can keep two scripting languages in my head. But
 Lua seems to be very simple.
I consider to maybe use Lua as scripting DSL in our app...we'll see...it's still too early to say...so, yes, it is cute language, but premake then resembles Waf with the exception of using Python instead.
Right. We will see what tool will finally win this race. Anyway I assume that there will be more tools around and likely people will move to new tools. autotools wasn't the final thing for configuring software. I just pick the one that works for me right now since there will be a better tool later anyway. But I hope that the tools for configuring software stabilizes more and more as time goes by. Jens
Feb 22 2011
parent Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 12:07:13 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 It does work for me most of the time. I work on Linux. There is one
 neat trick if you need to link against shared libraries which isn't
 supported by dmd yet. For these cases I rely on gcc.
 E.g.
 add_executable(myDExecutable src.d)
 set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C)
 target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES})
=20
 will link myDExecutable against libraries mentioned in
 CMAKE_REQUIRED_LIBRARIES.
Cute...Still, I've to learn more about CMake...
 Yeah. I'll guess though. But since it has it's own language some
 things are really annoying to do.=20
I could imagine...still cmake is meta-build system which uses established mechanisms to do the real build.
 I think the newer systems are better in that regard. They give you a
 nicer syntax and usually a full blown scripting language.
I would say that having full scripting language on disposal might be blessing as well as the curse. ;)
 I just pick the one that works for me right now since there will be
 a better tool later anyway.
Well, I do not like to think too much about build-system, but having one that 'just works'. Otherwise, it is distraction only taking focus away from the real work...In that vein I preferred using darcs as my DVCS or now using e.g. Fossil over Git. :-)
 But I hope that the tools for configuring software stabilizes more
 and more as time goes by.
I'm also going for stability and that's why I plan to move from Linux to free(pc)bsd soon. ;) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
prev sibling parent Gour <gour atmarama.net> writes:
On Mon, 21 Feb 2011 21:22:54 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 They also wrote in what regard CMake didn't work out for them
 http://code.google.com/p/gyp/wiki/GypVsCMake
I read it as well as http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/34829 thread, but nothing spectacular for me... This http://article.gmane.org/gmane.comp.programming.tools.cmake.user/34848 post is quite nice telling about Cmake vs. Gyp. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote:
[ . . . ]
 Can the code comprising the D support for CMake be "packaged" up so tha=
t
 it can be offerred to everyone direct from a DVCS repository?  SCons an=
d
 Waf have the tool concept to allow for this.  CMake must have something
 analogous.  People can then make use of the D support with their CMake
 without the necessity of it heading upstream -- though it would be good
 for that to happen eventually.
=20 Don't know how packaging is done in SCons/Waf.
No problem, I can handle that. Actually I didn't mean "packaging" as in creating a Debian/Ubuntu package, I meant more a plugin. SCons and Waf have the notion of tools that can be developed, and indeed, stored separately from the core. This is crucial for people using tools without having permission to install things into the core.=20
 With CMakeD, you clone the repository, i.e.
 $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
 and
 $ cd cmaked2/cmaked
 $ mkdir build
 $ cd build
 $ cmake ..
 $ make install
=20
 to install it. That will copy the necessary files into your CMake
 installation.
I haven't actually tried it yet I guess I should, but wouldn't that try to install into the system area? i.e. into the CMake installation. I don't allow any extra installation into the system area unless it is via a package.
 I'll guess SCons/Waf offers something more than that.
Yes :-) What I would like to do is to have the CMakeD be usable from a location different from where the rest of CMake is stored. In particular I'd like to use CMakeD out of the Mercurial clone I have. Is there a notion of CMake search path that would allow this so as to avoid installing as above?=20 [ . . . ]
 Yeah. I try to help, if I can. Don't hesitate asking. Though I have to
 admit I have almost no Python skills. I like Ruby more. It pleases my
 eyes and there seems to be only enough space for one scripting language
 in my head.
Python is not the issue, it is really more about algorithms and strategy. If CMakeD and the SCons D tool both realize the same comprehensive approach, I think everyone wins. It is quite a war the Python/Ruby/Groovy/Lua one. I tend to stick with Python for now as it has the greatest penetration in the market -- well except the Ruby on Rails one of course. [ . . . ]
 CMakeD just relies on dmd. But you're right it's a bit more complicated.
So you use DMD for compilation and linking? Currently in the SCons D tool, compilation of D is handled with DMD or GDC and then linking with the users choice of linker (usually GCC I guess).
 It seems that on Linux CMake has no proper way of cross building a 32
 bit/64 bit version. That kind of cross compiling does not seems to work.
 I would need to investigate further to find out whether it's a dmd
 problem. Usually I think for building a 32 bit C binary you just pass
 -m32 then the linker should search in ...lib32/. If you build a 64 bit
 binary it should search in ...lib64/. If you don't specify anything it's
 up to the compiler. CMake's task is just to check whether the dependent
 library is installed. I think at the moment it does not look in
 lib32/lib64 separately. In that sense it's support for cross compiling
 is weak. I may be wrong here.
Is perhaps a factor that DMD is itself a 32-bit application? For the SCons D tool I have had to manage the -I and -L paths fairly directly. [ . . . ]
 I do not know yet. I think both of them are pretty weak regarding
 already available modules, i.e. files to find a specific dependency. Gyp
 is developed for building Chromium. They had a problem with SCons while
 migrating to it.
I didn't know that (even though perhaps I should), I will investigate. Thanks for the tip.
 They also wrote in what regard CMake didn't work out for them
 http://code.google.com/p/gyp/wiki/GypVsCMake
 I like premake for it's readability see
 http://industriousone.com/sample-script
 and it's all Lua. Though I'm not sure whether I can keep two scripting
 languages in my head. But Lua seems to be very simple.
Lua and Python seem, between them, to have about a 100% monopoly on the dynamic language plugin market, at least in the media software arena. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 22 2011
parent David Nadlinger <see klickverbot.at> writes:
On 2/22/11 1:32 PM, Russel Winder wrote:
 Lua and Python seem, between them, to have about a 100% monopoly on the
 dynamic language plugin market, at least in the media software arena.
IIRC, Naughty Dog, the people behind the Uncharted series, are using something like PLT Scheme, i.e. LISP, for their scripting needs (e.g. http://gameenginebook.com/gdc09-statescripting-uncharted2). Nevertheless, »about 100%« is probably right. David
Feb 22 2011
prev sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Russel Winder wrote:
 On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote:
 [ . . . ]
 With CMakeD, you clone the repository, i.e.
 $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
 and
 $ cd cmaked2/cmaked
 $ mkdir build
 $ cd build
 $ cmake ..
 $ make install
 
 to install it. That will copy the necessary files into your CMake
 installation.
I haven't actually tried it yet I guess I should, but wouldn't that try to install into the system area? i.e. into the CMake installation. I don't allow any extra installation into the system area unless it is via a package.
Hmm. I do it like this. Download CMake from the official site and install it to /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed. And if I configure CMakeD using my cmake it will install the files to /path/to/myhome/local/where/cmake/puts/its/files.
 I'll guess SCons/Waf offers something more than that.
Yes :-) What I would like to do is to have the CMakeD be usable from a location different from where the rest of CMake is stored. In particular I'd like to use CMakeD out of the Mercurial clone I have. Is there a notion of CMake search path that would allow this so as to avoid installing as above?
Don't know. My feeling is no.
 CMakeD just relies on dmd. But you're right it's a bit more complicated.
So you use DMD for compilation and linking? Currently in the SCons D tool, compilation of D is handled with DMD or GDC and then linking with the users choice of linker (usually GCC I guess).
Yes. If you build an D executable then dmd will be used by default. I think this is good because on Windows there may be only the dmd compiler available. But you can tell CMake to use C's linker. set_target_properties(myExectable PROPERTIES LINKER_LANGUAGE C)
 It seems that on Linux CMake has no proper way of cross building a 32
 bit/64 bit version. That kind of cross compiling does not seems to work.
 I would need to investigate further to find out whether it's a dmd
 problem. Usually I think for building a 32 bit C binary you just pass
 -m32 then the linker should search in ...lib32/. If you build a 64 bit
 binary it should search in ...lib64/. If you don't specify anything it's
 up to the compiler. CMake's task is just to check whether the dependent
 library is installed. I think at the moment it does not look in
 lib32/lib64 separately. In that sense it's support for cross compiling
 is weak. I may be wrong here.
Is perhaps a factor that DMD is itself a 32-bit application?
I'll guess not.
 For the SCons D tool I have had to manage the -I and -L paths fairly
 directly.
Meaning you have to specify in the SCons file?
 They also wrote in what regard CMake didn't work out for them
 http://code.google.com/p/gyp/wiki/GypVsCMake
 I like premake for it's readability see
 http://industriousone.com/sample-script
 and it's all Lua. Though I'm not sure whether I can keep two scripting
 languages in my head. But Lua seems to be very simple.
Lua and Python seem, between them, to have about a 100% monopoly on the dynamic language plugin market, at least in the media software arena.
Yes. I heard Lua is heavily in the gaming industry. They use it to extend their games with scripting capabilities. I heard that Warcraft used it. Jens
Feb 22 2011
parent reply Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 14:10:59 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 Hmm. I do it like this.
 Download CMake from the official site and install it to
 /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed.
 And if I configure CMakeD using my cmake it will install the files to
 /path/to/myhome/local/where/cmake/puts/its/files.
I've asked on #cmake about the possibility to include CMakedD in the official release... Here are some tips I got: * "well it needs to be cleaned up more" * "as I said before the D support is not in a state that it can be accepted" * "you need to create a git branch add it" * "compile cmake and it needs to pass ctest -R ModuleNotices -V...and other stuff" I hope it helps and can be tailored for inclusion into release. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Tue, 22 Feb 2011 14:10:59 +0100
 Jens Mueller <jens.k.mueller gmx.de> wrote:
 
 Hmm. I do it like this.
 Download CMake from the official site and install it to
 /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed.
 And if I configure CMakeD using my cmake it will install the files to
 /path/to/myhome/local/where/cmake/puts/its/files.
I've asked on #cmake about the possibility to include CMakedD in the official release...
Thank you for asking.
 Here are some tips I got:
 
 * "well it needs to be cleaned up more"
Definitely.
 * "as I said before the D support is not in a state that it can be accepted"
I heard that. CMakeD had so many maintainers in such a short time. I think they already asked for it a while ago.
 * "you need to create a git branch add it"
Minor problem. I prefer git.
 * "compile cmake and it needs to pass ctest -R ModuleNotices -V...and
   other stuff"
I do not know about these internals.
 I hope it helps and can be tailored for inclusion into release.
I mainly push it as far as I need it because writing CMake code is no fun for me (and I do it in my free time). Further I have the impression that nobody really cares. I mean there _many_ viable ways to have better configuration/build support for D. Jens
Feb 22 2011
parent reply Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 15:33:48 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 I mainly push it as far as I need it because writing CMake code is no
 fun for me (and I do it in my free time).=20
Thank you.
 Further I have the impression that nobody really cares. I mean there
 _many_ viable ways to have better configuration/build support for D.
Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language. I'll try to help as soon as I become somewhat (more) familiar with Cmake and its 'language'. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Gour wrote:
 On Tue, 22 Feb 2011 15:33:48 +0100
 Jens Mueller <jens.k.mueller gmx.de> wrote:
 
 Further I have the impression that nobody really cares. I mean there
 _many_ viable ways to have better configuration/build support for D.
Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language.
Yeah. My point is just that I don't know whether CMake will be the way to go. I mean it works but there are more elegant build tools in the pipeline. That's why I push it only as far as it needs to be.
 I'll try to help as soon as I become somewhat (more) familiar with
 Cmake and its 'language'.
That would be very nice. So far we have quite decent support for * dmd (tested on Linux/Windows) * gdc (tested on Linux) Linking shared libraries on Linux using the C linker is also nice to have. This way you can use your favorite third-party C library in D. I also wanted to test it on Mac OS X but unfortunately I do not have access to a Mac. Looking into ldc may be also worthwhile. I did to a certain degree. But I never got a simple program to link. Jens
Feb 22 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 2/22/11 6:10 PM, Jens Mueller wrote:
 I also wanted to test it on Mac OS X but unfortunately I do not have
 access to a Mac.
I don't have lots of time for experiments at the moment, but I'd be glad to help you out if you just need someone to run an existing set of tests on OS X or something. David
Feb 22 2011
parent Jens Mueller <jens.k.mueller gmx.de> writes:
David Nadlinger wrote:
 On 2/22/11 6:10 PM, Jens Mueller wrote:
I also wanted to test it on Mac OS X but unfortunately I do not have
access to a Mac.
I don't have lots of time for experiments at the moment, but I'd be glad to help you out if you just need someone to run an existing set of tests on OS X or something.
That would be great. I want to fix issue http://code.google.com/p/cmaked2/issues/detail?id=8 For this you need to install CMake. There is a Universal Mac OSX Binary available at http://www.cmake.org/cmake/resources/software.html And then you can follow http://code.google.com/p/cmaked2/wiki/GettingStarted to install CMakeD. Then update the issue or send me the failing output. I hope it works out. Jens
Feb 22 2011
prev sibling parent Gour <gour atmarama.net> writes:
On Tue, 22 Feb 2011 18:10:11 +0100
Jens Mueller <jens.k.mueller gmx.de> wrote:

 Yeah. My point is just that I don't know whether CMake will be the way
 to go. I mean it works but there are more elegant build tools in the
 pipeline. That's why I push it only as far as it needs to be.
Well, other, 'more elegant tools' are still immature, small userbase, not so many devs. On top of that, it's not certain on how many platforms they work, while seeing something like http://www.cdash.org/CDash/index.php?project=3DCMake is definitely impressive for me.
 That would be very nice.
 So far we have quite decent support for
 * dmd (tested on Linux/Windows)
 * gdc (tested on Linux)
Cool. Soon, when I install (free)pcbsd, I can test on it. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Feb 22 2011
prev sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jens Mueller wrote:
 Gour wrote:
 On Tue, 22 Feb 2011 15:33:48 +0100
 Jens Mueller <jens.k.mueller gmx.de> wrote:
 
 Further I have the impression that nobody really cares. I mean there
 _many_ viable ways to have better configuration/build support for D.
Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language.
Yeah. My point is just that I don't know whether CMake will be the way to go. I mean it works but there are more elegant build tools in the pipeline. That's why I push it only as far as it needs to be.
 I'll try to help as soon as I become somewhat (more) familiar with
 Cmake and its 'language'.
That would be very nice. So far we have quite decent support for * dmd (tested on Linux/Windows) * gdc (tested on Linux) Linking shared libraries on Linux using the C linker is also nice to have. This way you can use your favorite third-party C library in D.
I shouldn't have said nice to have. Because it sounds as if we want it but don't have it. It is already available thus allowing you to link with shared libraries. Jens
Feb 22 2011