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