CMake for D2 ready for testers

[SK]

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

[Nick Sabalausky]

"SK" <sk at metrokings.com> wrote in message

Post by SK
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
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,
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?

[Jonathan M Davis]

Post by Nick Sabalausky
"SK" <sk at metrokings.com> wrote in message

Post by SK
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
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,
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

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisprog at gmail.com> wrote in message

Post by Jonathan M Davis

Post by Nick Sabalausky
"SK" <sk at metrokings.com> wrote in message

Post by SK
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
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,
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.

Post by Jonathan M Davis
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.

[Jonathan M Davis]

Post by Nick Sabalausky
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

[SK]

Post by Nick Sabalausky
"Jonathan M Davis" <jmdavisprog at gmail.com> wrote in message

Post by Jonathan M Davis

Post by Nick Sabalausky
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

[LMB]

Haven't tried it yet, but thank you very much! This is something I missed a lot :-)

LMB

Post by SK
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
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,
http://www.cmake.org.
Cheers,
-steve

[klickverbot]

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.

[Gareth Charnock]

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.)

Post by SK
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
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,
http://www.cmake.org.
Cheers,
-steve

[Gour D.]

On Sun, 5 Sep 2010 22:28:41 -0700
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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101008/d0d8aee5/attachment.pgp>

[Russel Winder]

Post by Gour D.
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101008/7b6767a4/attachment.pgp>

[Jens Mueller]

Post by Russel Winder

Post by Gour D.
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.

Post by Russel Winder
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
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

[Russel Winder]

Post by Jens Mueller

Post by Russel Winder

Post by Gour D.
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
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.

Post by Jens Mueller
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.

Post by Jens Mueller
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.

Post by Jens Mueller

Post by Russel Winder
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
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.

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.

Post by Jens Mueller
On top of my head some things I find nice in CMake. Just curious whether
Scons/Waf have similar features.
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.

Post by Jens Mueller
* 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

Post by Jens Mueller
* Publishing build/test results

Isn't that the job of the continuous integration server?

Post by Jens Mueller
* 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.

Post by Jens Mueller
* 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

Post by Jens Mueller
* Valgrind/Purify integration

I believe both have this but I don't know, in my C++ programming I never
use these tools.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/196ddbdc/attachment.pgp>

[Jens Mueller]

Post by Russel Winder

Post by Jens Mueller

Post by Russel Winder
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
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.

Post by Russel Winder

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller
On top of my head some things I find nice in CMake. Just curious whether
Scons/Waf have similar features.
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.

Post by Russel Winder

Post by Jens Mueller
* 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.

Post by Russel Winder

Post by Jens Mueller
* 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.

Post by Russel Winder

Post by Jens Mueller
* 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.

Post by Russel Winder
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.

Post by Russel Winder

Post by Jens Mueller
* 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

Post by Russel Winder

Post by Jens Mueller
* 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

[klickverbot]

Post by Russel Winder
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/

[Russel Winder]

Post by klickverbot
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?

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.

Post by klickverbot
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.

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.

Post by klickverbot
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.

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.

Post by klickverbot
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.

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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/8758ac22/attachment.pgp>

[SK]

Post by Jens Mueller
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.

[Gour D.]

On Fri, 8 Oct 2010 21:41:55 +0200
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='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"

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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/aa7a7aa7/attachment.pgp>

[Russel Winder]

On Sat, 2010-10-09 at 00:16 +0200, Gour D. wrote:
[ . . . ]

Post by Gour D.
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!

[ . . . ]

Post by Gour D.
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.

Post by Gour D.
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,.

[ . . . ]

Post by Gour D.
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?

Post by Gour D.
Jens> * Publishing build/test results
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.

Post by Gour D.
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.

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.

[ . . . ]

Post by Gour D.
In any case, it's interesting and we'll put it on our evaluation-list.

Happy evoluation :-)
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/c589ac06/attachment.pgp>

[Jens Mueller]

Post by Gour D.
On Fri, 8 Oct 2010 21:41:55 +0200
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.

Post by Gour D.
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.
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.

Post by Gour D.
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
http://code.google.com/p/waf/
http://freehackers.org/~tnagy/wafbook160p3/

Wow. They have excellent documentation.

Post by Gour D.
Jens> find_package(GTest REQUIRED)
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.

Post by Gour D.
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.

Post by Gour D.
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.

Post by Gour D.
Jens> * Valgrind/Purify integration
http://wiki.samba.org/index.php/Debugging_individual_tests

Interesting.

Post by Gour D.
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

[Russel Winder]

On Sat, 2010-10-09 at 12:06 +0200, Jens Mueller wrote:
[ . . . ]

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller

Post by Gour D.
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.

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.

[ . . . ]

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller

Post by Gour D.
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.

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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/de8a5b0e/attachment.pgp>

[Gour D.]

On Sat, 09 Oct 2010 11:30:44 +0100
Russel> > Can you keep me informed about the result? Just curious which
Russel> > features influenced your final decision.
Russel>
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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/d7a7e656/attachment.pgp>

[Gour D.]

On Sat, 9 Oct 2010 16:48:15 +0200
Gour> Rationale?

I forgot to add:

x) deps are determined by hash and not by timestamps


Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101010/c58782ac/attachment.pgp>

[Gour D.]

On Sat, 09 Oct 2010 10:56:45 +0100
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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/b080642d/attachment.pgp>

[Gour D.]

On Sat, 9 Oct 2010 12:06:46 +0200
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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/e73ae531/attachment-0001.pgp>

[Gour D.]

On Fri, 08 Oct 2010 17:26:25 +0100
Russel> For C, C++, Fortran, and hence D, I personally find CMake
Russel> awkward and clumsy.

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).

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.

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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101008/556adefa/attachment.pgp>

[Russel Winder]

Post by Gour D.
On Fri, 08 Oct 2010 17:26:25 +0100
Russel> For C, C++, Fortran, and hence D, I personally find CMake
Russel> awkward and clumsy.
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.

Post by Gour D.
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).
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.

Post by Gour D.
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.
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?

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.

Post by Gour D.
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...

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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/2365df2d/attachment.pgp>

[Gour D.]

On Sat, 09 Oct 2010 10:19:50 +0100
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
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/e6645817/attachment.pgp>

[Gour]

On Sun, 5 Sep 2010 22:28:41 -0700

Post by SK
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110221/0d414a9f/attachment.pgp>

[Russel Winder]

On Mon, 2011-02-21 at 11:31 +0100, Gour wrote:
[ . . . ]

Post by Gour
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?

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.

Post by Gour
Any hope that D support will be applied in upstream?
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
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110221/c1ca5af4/attachment.pgp>

[Gour]

On Mon, 21 Feb 2011 10:56:50 +0000

Post by Russel Winder

Post by Gour
Any hope that D support will be applied in upstream?
What about 64bit support in dmd2?

Are you talking about CMake or SCons here?

CMake.

Post by Russel Winder
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110221/b6b79003/attachment.pgp>

[Jens Mueller]

Post by Gour D.
On Sun, 5 Sep 2010 22:28:41 -0700

Post by SK
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.

Post by Gour D.
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

[Russel Winder]

On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote:
[ . . . ]

Post by Jens Mueller
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.

Post by Jens Mueller
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.

Post by Jens Mueller

Post by Gour
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?

Post by Jens Mueller
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110221/a6e1f3f1/attachment.pgp>

[Jens Mueller]

Post by Russel Winder
[ . . . ]

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller

Post by Gour
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.

Post by Russel Winder

Post by Jens Mueller
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

[Russel Winder]

On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote:
[ . . . ]

Post by Jens Mueller

Post by Russel Winder
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.

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.

Post by Jens Mueller
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.

Post by Jens Mueller
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?

[ . . . ]

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller
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).

Post by Jens Mueller
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.

[ . . . ]

Post by Jens Mueller
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.

Post by Jens Mueller
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.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/2a58c887/attachment.pgp>

[Jens Mueller]

Post by Russel Winder
[ . . . ]

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller
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.

Post by Russel Winder

Post by Jens Mueller
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)

Post by Russel Winder

Post by Jens Mueller
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.

Post by Russel Winder
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?

Post by Russel Winder

Post by Jens Mueller
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

[Gour]

On Tue, 22 Feb 2011 14:10:59 +0100

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/ab03db33/attachment.pgp>

[Jens Mueller]

Post by Gour
On Tue, 22 Feb 2011 14:10:59 +0100

Post by Jens Mueller
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.

Post by Gour
* "well it needs to be cleaned up more"

Definitely.

Post by Gour
* "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.

Post by Gour
* "you need to create a git branch add it"

Minor problem. I prefer git.

Post by Gour
* "compile cmake and it needs to pass ctest -R ModuleNotices -V...and
other stuff"

I do not know about these internals.

Post by Gour
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

[Gour]

On Tue, 22 Feb 2011 15:33:48 +0100

Post by Jens Mueller
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).

Thank you.

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/b06c8917/attachment.pgp>

[Jens Mueller]

Post by Gour
On Tue, 22 Feb 2011 15:33:48 +0100

Post by Jens Mueller
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.

Post by Gour
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

[Jens Mueller]

Post by Jens Mueller

Post by Gour
On Tue, 22 Feb 2011 15:33:48 +0100

Post by Jens Mueller
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.

Post by Gour
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

[David Nadlinger]

Post by Jens Mueller
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

[Jens Mueller]

Post by David Nadlinger

Post by Jens Mueller
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

[Gour]

On Tue, 22 Feb 2011 18:10:11 +0100

Post by Jens Mueller
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=CMake

is definitely impressive for me.

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/73bd6e81/attachment.pgp>

[David Nadlinger]

Post by Russel Winder
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

[Gour]

On Mon, 21 Feb 2011 21:22:54 +0100

Post by Jens Mueller
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 at 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?

Post by Jens Mueller
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.

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/8d52b637/attachment.pgp>

[Gour]

On Tue, 22 Feb 2011 09:42:46 +0100

Post by Gour
I installed CMakeD from the archlinux package, then pulled from the

Oops...forgot to run 'make test':

[gour at atmarama build] make test
Running tests...
Test project /home/gour/repos/cmaked2/tests/build
Start 1: app_1
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................ Passed 0.00 sec
Start 8: moduleB.d
8/9 Test #8: moduleB.d ........................ Passed 0.05 sec
Start 9: moduleA.d
9/9 Test #9: moduleA.d ........................ Passed 0.05 sec

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).


Sincerely,
Gour
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/d5d670c3/attachment.pgp>

[Jens Mueller]

Post by Gour
On Tue, 22 Feb 2011 09:42:46 +0100

Post by Gour
I installed CMakeD from the archlinux package, then pulled from the

[gour at atmarama build] make test
Running tests...
Test project /home/gour/repos/cmaked2/tests/build
Start 1: app_1
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................ Passed 0.00 sec
Start 8: moduleB.d
8/9 Test #8: moduleB.d ........................ Passed 0.05 sec
Start 9: moduleA.d
9/9 Test #9: moduleA.d ........................ Passed 0.05 sec
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

[Jens Mueller]

Post by Gour
On Tue, 22 Feb 2011 09:42:46 +0100

Post by Gour
I installed CMakeD from the archlinux package, then pulled from the

[gour at atmarama build] make test
Running tests...
Test project /home/gour/repos/cmaked2/tests/build
Start 1: app_1
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................ Passed 0.00 sec
Start 8: moduleB.d
8/9 Test #8: moduleB.d ........................ Passed 0.05 sec
Start 9: moduleA.d
9/9 Test #9: moduleA.d ........................ Passed 0.05 sec
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
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................***Exception: SegFault 0.01 sec
Start 8: moduleA.d
8/9 Test #8: moduleA.d ........................ Passed 0.15 sec
Start 9: moduleB.d
9/9 Test #9: moduleB.d ........................ Passed 0.11 sec

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

[Jens Mueller]

Post by Jens Mueller

Post by Gour
On Tue, 22 Feb 2011 09:42:46 +0100

Post by Gour
I installed CMakeD from the archlinux package, then pulled from the

[gour at atmarama build] make test
Running tests...
Test project /home/gour/repos/cmaked2/tests/build
Start 1: app_1
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................ Passed 0.00 sec
Start 8: moduleB.d
8/9 Test #8: moduleB.d ........................ Passed 0.05 sec
Start 9: moduleA.d
9/9 Test #9: moduleA.d ........................ Passed 0.05 sec
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
1/9 Test #1: app_1 ............................ Passed 0.00 sec
Start 2: app_2
2/9 Test #2: app_2 ............................ Passed 0.00 sec
Start 3: app_3
3/9 Test #3: app_3 ............................ Passed 0.00 sec
Start 4: app_5
4/9 Test #4: app_5 ............................ Passed 0.00 sec
Start 5: app_4
5/9 Test #5: app_4 ............................ Passed 0.00 sec
Start 6: app_6
6/9 Test #6: app_6 ............................ Passed 0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ............................***Exception: SegFault 0.01 sec
Start 8: moduleA.d
8/9 Test #8: moduleA.d ........................ Passed 0.15 sec
Start 9: moduleB.d
9/9 Test #9: moduleB.d ........................ Passed 0.11 sec
89% tests passed, 1 tests failed out of 9
Total Test time (real) = 0.30 sec
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

[Gour]

On Tue, 22 Feb 2011 12:10:08 +0100

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/7cd0af4a/attachment.pgp>

[Jens Mueller]

Post by Gour
On Mon, 21 Feb 2011 21:22:54 +0100

Post by Jens Mueller
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
[gour at 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.

Post by Gour

Post by Jens Mueller
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.

Post by Gour
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.

Post by Gour

Post by Jens Mueller
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

[Gour]

On Tue, 22 Feb 2011 12:07:13 +0100

Post by Jens Mueller
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.

Cute...Still, I've to learn more about CMake...

Post by Jens Mueller
Yeah. I'll guess though. But since it has it's own language some
things are really annoying to do.

I could imagine...still cmake is meta-build system which uses
established mechanisms to do the real build.

Post by Jens Mueller
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. ;)

Post by Jens Mueller
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. :-)

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/08210ef6/attachment.pgp>

[Gour]

On Mon, 21 Feb 2011 21:22:54 +0100

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/8a384759/attachment.pgp>

[Gour]

On Mon, 21 Feb 2011 12:40:11 +0100

Post by Jens Mueller
I don't know about upstreaming it. Certainly it would be nice. But for
doing so I need polish it further.

OK.

Post by Jens Mueller
It seems that not many people are using CMakeD and there seems to be
less interest in it.

I believe many are waiting that D(2) become consolidated a bit, 64bit
port etc. At least, I'm the one of them. :-)

Post by Jens Mueller
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.

Post by Jens Mueller
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
--
?In the material world, conceptions of good and bad are
all mental speculations?? (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110221/933ee3d3/attachment.pgp>

[Jens Mueller]

Post by Gour
On Mon, 21 Feb 2011 12:40:11 +0100

Post by Jens Mueller
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