Re: CMake for D2 ready for testers
On Mon, 21 Feb 2011 21:22:54 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: With CMakeD, you clone the repository, i.e. $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2 and $ cd cmaked2/cmaked $ mkdir build $ cd build $ cmake .. $ make install to install it. That will copy the necessary files into your CMake installation. I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: [gour@atmarama tests] make Scanning dependencies of target lib_1 [ 10%] Building D object lib_1/CMakeFiles/lib_1.dir/lib_1.o Linking D static library liblib_1.a [ 10%] Built target lib_1 Scanning dependencies of target lib_2 [ 20%] Building C object lib_2/CMakeFiles/lib_2.dir/lib_2.o Linking C static library liblib_2.a [ 20%] Built target lib_2 Scanning dependencies of target app_1 [ 30%] Building D object app_1/CMakeFiles/app_1.dir/app_1.o Linking D executable app_1 [ 30%] Built target app_1 Scanning dependencies of target app_2 [ 40%] Building D object app_2/CMakeFiles/app_2.dir/app_2.o Linking D executable app_2 [ 40%] Built target app_2 Scanning dependencies of target app_3 [ 50%] Building D object app_3/CMakeFiles/app_3.dir/app_3.o Linking D executable app_3 [ 50%] Built target app_3 Scanning dependencies of target app_5 [ 60%] Building D object app_5/CMakeFiles/app_5.dir/app_5.o [ 70%] Building C object app_5/CMakeFiles/app_5.dir/cfunc.o Linking D executable app_5 [ 70%] Built target app_5 Scanning dependencies of target app_4 [ 80%] Building D object app_4/CMakeFiles/app_4.dir/app_4.o Linking D executable app_4 [ 80%] Built target app_4 Scanning dependencies of target app_6 [ 90%] Building D object app_6/CMakeFiles/app_6.dir/app_6.o Linking D executable app_6 [ 90%] Built target app_6 Scanning dependencies of target app_7 [100%] Building D object app_7/CMakeFiles/app_7.dir/app_7.o std.perf has been scheduled for deprecation. Please use std.datetime instead. Linking D executable app_7 [100%] Built target app_7 Is it OK? I do not know yet. I think both of them are pretty weak regarding already available modules, i.e. files to find a specific dependency. Gyp is developed for building Chromium. They had a problem with SCons while migrating to it. They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake Do you have any issue with CMake that it does not work for you? Considering that KDE is (still) using it, I assume that, despite its possible awkwardness, it must be quite robust build system. I like premake for it's readability see http://industriousone.com/sample-script and it's all Lua. Though I'm not sure whether I can keep two scripting languages in my head. But Lua seems to be very simple. I consider to maybe use Lua as scripting DSL in our app...we'll see...it's still too early to say...so, yes, it is cute language, but premake then resembles Waf with the exception of using Python instead. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 09:42:46 +0100 Gour g...@atmarama.net wrote: I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: Oops...forgot to run 'make test': [gour@atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 1/9 Test #1: app_1 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.00 sec Start 7: app_7 7/9 Test #7: app_7 Passed0.00 sec Start 8: moduleB.d 8/9 Test #8: moduleB.d Passed0.05 sec Start 9: moduleA.d 9/9 Test #9: moduleA.d Passed0.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 signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Mon, 21 Feb 2011 21:22:54 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake I read it as well as http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/34829 thread, but nothing spectacular for me... This http://article.gmane.org/gmane.comp.programming.tools.cmake.user/34848 post is quite nice telling about Cmake vs. Gyp. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
Gour wrote:
On Mon, 21 Feb 2011 21:22:54 +0100
Jens Mueller jens.k.muel...@gmx.de wrote:
With CMakeD, you clone the repository, i.e.
$ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
and
$ cd cmaked2/cmaked
$ mkdir build
$ cd build
$ cmake ..
$ make install
to install it. That will copy the necessary files into your CMake
installation.
I installed CMakeD from the archlinux package, then pulled from the
repo and tried tests suite. Here is the result:
[gour@atmarama tests] make
Scanning dependencies of target lib_1
[ 10%] Building D object lib_1/CMakeFiles/lib_1.dir/lib_1.o
Linking D static library liblib_1.a
[ 10%] Built target lib_1
Scanning dependencies of target lib_2
[ 20%] Building C object lib_2/CMakeFiles/lib_2.dir/lib_2.o
Linking C static library liblib_2.a
[ 20%] Built target lib_2
Scanning dependencies of target app_1
[ 30%] Building D object app_1/CMakeFiles/app_1.dir/app_1.o
Linking D executable app_1
[ 30%] Built target app_1
Scanning dependencies of target app_2
[ 40%] Building D object app_2/CMakeFiles/app_2.dir/app_2.o
Linking D executable app_2
[ 40%] Built target app_2
Scanning dependencies of target app_3
[ 50%] Building D object app_3/CMakeFiles/app_3.dir/app_3.o
Linking D executable app_3
[ 50%] Built target app_3
Scanning dependencies of target app_5
[ 60%] Building D object app_5/CMakeFiles/app_5.dir/app_5.o
[ 70%] Building C object app_5/CMakeFiles/app_5.dir/cfunc.o
Linking D executable app_5
[ 70%] Built target app_5
Scanning dependencies of target app_4
[ 80%] Building D object app_4/CMakeFiles/app_4.dir/app_4.o
Linking D executable app_4
[ 80%] Built target app_4
Scanning dependencies of target app_6
[ 90%] Building D object app_6/CMakeFiles/app_6.dir/app_6.o
Linking D executable app_6
[ 90%] Built target app_6
Scanning dependencies of target app_7
[100%] Building D object app_7/CMakeFiles/app_7.dir/app_7.o
std.perf has been scheduled for deprecation. Please use std.datetime
instead.
Linking D executable app_7
[100%] Built target app_7
Is it OK?
That looks good.
I do not know yet. I think both of them are pretty weak regarding
already available modules, i.e. files to find a specific dependency.
Gyp is developed for building Chromium. They had a problem with SCons
while migrating to it.
They also wrote in what regard CMake didn't work out for them
http://code.google.com/p/gyp/wiki/GypVsCMake
Do you have any issue with CMake that it does not work for you?
It does work for me most of the time. I work on Linux. There is one neat
trick if you need to link against shared libraries which isn't supported
by dmd yet. For these cases I rely on gcc.
E.g.
add_executable(myDExecutable src.d)
set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C)
target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES})
will link myDExecutable against libraries mentioned in
CMAKE_REQUIRED_LIBRARIES.
Considering that KDE is (still) using it, I assume that, despite its
possible awkwardness, it must be quite robust build system.
Yeah. I'll guess though. But since it has it's own language some things
are really annoying to do. I think the newer systems are better in that
regard. They give you a nicer syntax and usually a full blown scripting
language.
I like premake for it's readability see
http://industriousone.com/sample-script and it's all Lua. Though I'm
not sure whether I can keep two scripting languages in my head. But
Lua seems to be very simple.
I consider to maybe use Lua as scripting DSL in our app...we'll
see...it's still too early to say...so, yes, it is cute language, but
premake then resembles Waf with the exception of using Python instead.
Right. We will see what tool will finally win this race. Anyway I assume
that there will be more tools around and likely people will move to new
tools. autotools wasn't the final thing for configuring software.
I just pick the one that works for me right now since there will be a
better tool later anyway. But I hope that the tools for configuring
software stabilizes more and more as time goes by.
Jens
Re: CMake for D2 ready for testers
Gour wrote: On Tue, 22 Feb 2011 09:42:46 +0100 Gour g...@atmarama.net wrote: I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: Oops...forgot to run 'make test': [gour@atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 1/9 Test #1: app_1 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.00 sec Start 7: app_7 7/9 Test #7: app_7 Passed0.00 sec Start 8: moduleB.d 8/9 Test #8: moduleB.d Passed0.05 sec Start 9: moduleA.d 9/9 Test #9: moduleA.d Passed0.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
Re: CMake for D2 ready for testers
Gour wrote: On Mon, 21 Feb 2011 12:40:11 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Recently I've been a bit distracted from CMakeD development since I stumbled over Gyp http://code.google.com/p/gyp/ and Premake http://industriousone.com/premake Both address similar needs like CMake but do not support D yet. They look interesting, but I'm sure they cannot replace CMake and therefore hope D will become 1st class citizen in the CMake country. Very true. CMake is used widely and has built-in support for finding different often used library like Boost, SDL, OpenSSL, ... So if you need to use these library CMake is a good candidate. Jens
Re: CMake for D2 ready for testers
Gour wrote: On Tue, 22 Feb 2011 09:42:46 +0100 Gour g...@atmarama.net wrote: I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: Oops...forgot to run 'make test': [gour@atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 1/9 Test #1: app_1 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.00 sec Start 7: app_7 7/9 Test #7: app_7 Passed0.00 sec Start 8: moduleB.d 8/9 Test #8: moduleB.d Passed0.05 sec Start 9: moduleA.d 9/9 Test #9: moduleA.d Passed0.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 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.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 Passed0.15 sec Start 9: moduleB.d 9/9 Test #9: moduleB.d Passed0.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
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 12:10:08 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Yeah. That looks good. I'd like to add your setup to http://code.google.com/p/cmaked2/wiki/TestedPlatforms Can please you leave a comment there? Done. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 12:07:13 +0100
Jens Mueller jens.k.muel...@gmx.de wrote:
It does work for me most of the time. I work on Linux. There is one
neat trick if you need to link against shared libraries which isn't
supported by dmd yet. For these cases I rely on gcc.
E.g.
add_executable(myDExecutable src.d)
set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C)
target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES})
will link myDExecutable against libraries mentioned in
CMAKE_REQUIRED_LIBRARIES.
Cute...Still, I've to learn more about CMake...
Yeah. I'll guess though. But since it has it's own language some
things are really annoying to do.
I could imagine...still cmake is meta-build system which uses
established mechanisms to do the real build.
I think the newer systems are better in that regard. They give you a
nicer syntax and usually a full blown scripting language.
I would say that having full scripting language on disposal might be
blessing as well as the curse. ;)
I just pick the one that works for me right now since there will be
a better tool later anyway.
Well, I do not like to think too much about build-system, but having
one that 'just works'. Otherwise, it is distraction only taking focus
away from the real work...In that vein I preferred using darcs as my
DVCS or now using e.g. Fossil over Git. :-)
But I hope that the tools for configuring software stabilizes more
and more as time goes by.
I'm also going for stability and that's why I plan to move from Linux
to free(pc)bsd soon. ;)
Sincerely,
Gour
--
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)
http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
signature.asc
Description: PGP signature
Re: CMake for D2 ready for testers
On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote: [ . . . ] Can the code comprising the D support for CMake be packaged up so 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. 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. 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? [ . . . ] Yeah. I try to help, if I can. Don't hesitate asking. Though I have to admit I have almost no Python skills. I like Ruby more. It pleases my eyes and there seems to be only enough space for one scripting language in my head. Python is not the issue, it is really more about algorithms and strategy. If CMakeD and the SCons D tool both realize the same comprehensive approach, I think everyone wins. It is quite a war the Python/Ruby/Groovy/Lua one. I tend to stick with Python for now as it has the greatest penetration in the market -- well except the Ruby on Rails one of course. [ . . . ] CMakeD just relies on dmd. But you're right it's a bit more complicated. So you use DMD for compilation and linking? Currently in the SCons D tool, compilation of D is handled with DMD or GDC and then linking with the users choice of linker (usually GCC I guess). It seems that on Linux CMake has no proper way of cross building a 32 bit/64 bit version. That kind of cross compiling does not seems to work. I would need to investigate further to find out whether it's a dmd problem. Usually I think for building a 32 bit C binary you just pass -m32 then the linker should search in ...lib32/. If you build a 64 bit binary it should search in ...lib64/. If you don't specify anything it's up to the compiler. CMake's task is just to check whether the dependent library is installed. I think at the moment it does not look in lib32/lib64 separately. In that sense it's support for cross compiling is weak. I may be wrong here. Is perhaps a factor that DMD is itself a 32-bit application? For the SCons D tool I have had to manage the -I and -L paths fairly directly. [ . . . ] I do not know yet. I think both of them are pretty weak regarding already available modules, i.e. files to find a specific dependency. Gyp is developed for building Chromium. They had a problem with SCons while migrating to it. I didn't know that (even though perhaps I should), I will investigate. Thanks for the tip. They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake I like premake for it's readability see http://industriousone.com/sample-script and it's all Lua. Though I'm not sure whether I can keep two scripting languages in my head. But Lua seems to be very simple. Lua and Python seem, between them, to have about a 100% monopoly on the dynamic language plugin market, at least in the media software arena. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
Russel Winder wrote: On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote: [ . . . ] With CMakeD, you clone the repository, i.e. $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2 and $ cd cmaked2/cmaked $ mkdir build $ cd build $ cmake .. $ make install to install it. That will copy the necessary files into your CMake installation. I haven't actually tried it yet I guess I should, but wouldn't that try to install into the system area? i.e. into the CMake installation. I don't allow any extra installation into the system area unless it is via a package. Hmm. I do it like this. Download CMake from the official site and install it to /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed. And if I configure CMakeD using my cmake it will install the files to /path/to/myhome/local/where/cmake/puts/its/files. I'll guess SCons/Waf offers something more than that. Yes :-) What I would like to do is to have the CMakeD be usable from a location different from where the rest of CMake is stored. In particular I'd like to use CMakeD out of the Mercurial clone I have. Is there a notion of CMake search path that would allow this so as to avoid installing as above? Don't know. My feeling is no. CMakeD just relies on dmd. But you're right it's a bit more complicated. So you use DMD for compilation and linking? Currently in the SCons D tool, compilation of D is handled with DMD or GDC and then linking with the users choice of linker (usually GCC I guess). Yes. If you build an D executable then dmd will be used by default. I think this is good because on Windows there may be only the dmd compiler available. But you can tell CMake to use C's linker. set_target_properties(myExectable PROPERTIES LINKER_LANGUAGE C) It seems that on Linux CMake has no proper way of cross building a 32 bit/64 bit version. That kind of cross compiling does not seems to work. I would need to investigate further to find out whether it's a dmd problem. Usually I think for building a 32 bit C binary you just pass -m32 then the linker should search in ...lib32/. If you build a 64 bit binary it should search in ...lib64/. If you don't specify anything it's up to the compiler. CMake's task is just to check whether the dependent library is installed. I think at the moment it does not look in lib32/lib64 separately. In that sense it's support for cross compiling is weak. I may be wrong here. Is perhaps a factor that DMD is itself a 32-bit application? I'll guess not. For the SCons D tool I have had to manage the -I and -L paths fairly directly. Meaning you have to specify in the SCons file? They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake I like premake for it's readability see http://industriousone.com/sample-script and it's all Lua. Though I'm not sure whether I can keep two scripting languages in my head. But Lua seems to be very simple. Lua and Python seem, between them, to have about a 100% monopoly on the dynamic language plugin market, at least in the media software arena. Yes. I heard Lua is heavily in the gaming industry. They use it to extend their games with scripting capabilities. I heard that Warcraft used it. Jens
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 14:10:59 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Hmm. I do it like this. Download CMake from the official site and install it to /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed. And if I configure CMakeD using my cmake it will install the files to /path/to/myhome/local/where/cmake/puts/its/files. I've asked on #cmake about the possibility to include CMakedD in the official release... Here are some tips I got: * well it needs to be cleaned up more * as I said before the D support is not in a state that it can be accepted * you need to create a git branch add it * compile cmake and it needs to pass ctest -R ModuleNotices -V...and other stuff I hope it helps and can be tailored for inclusion into release. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
Jens Mueller wrote: Gour wrote: On Tue, 22 Feb 2011 09:42:46 +0100 Gour g...@atmarama.net wrote: I installed CMakeD from the archlinux package, then pulled from the repo and tried tests suite. Here is the result: Oops...forgot to run 'make test': [gour@atmarama build] make test Running tests... Test project /home/gour/repos/cmaked2/tests/build Start 1: app_1 1/9 Test #1: app_1 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.00 sec Start 7: app_7 7/9 Test #7: app_7 Passed0.00 sec Start 8: moduleB.d 8/9 Test #8: moduleB.d Passed0.05 sec Start 9: moduleA.d 9/9 Test #9: moduleA.d Passed0.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 Passed0.00 sec Start 2: app_2 2/9 Test #2: app_2 Passed0.00 sec Start 3: app_3 3/9 Test #3: app_3 Passed0.00 sec Start 4: app_5 4/9 Test #4: app_5 Passed0.00 sec Start 5: app_4 5/9 Test #5: app_4 Passed0.00 sec Start 6: app_6 6/9 Test #6: app_6 Passed0.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 Passed0.15 sec Start 9: moduleB.d 9/9 Test #9: moduleB.d Passed0.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. 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
Re: CMake for D2 ready for testers
Gour wrote: On Tue, 22 Feb 2011 14:10:59 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Hmm. I do it like this. Download CMake from the official site and install it to /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed. And if I configure CMakeD using my cmake it will install the files to /path/to/myhome/local/where/cmake/puts/its/files. I've asked on #cmake about the possibility to include CMakedD in the official release... Thank you for asking. Here are some tips I got: * well it needs to be cleaned up more Definitely. * as I said before the D support is not in a state that it can be accepted I heard that. CMakeD had so many maintainers in such a short time. I think they already asked for it a while ago. * you need to create a git branch add it Minor problem. I prefer git. * compile cmake and it needs to pass ctest -R ModuleNotices -V...and other stuff I do not know about these internals. I hope it helps and can be tailored for inclusion into release. I mainly push it as far as I need it because writing CMake code is no fun for me (and I do it in my free time). Further I have the impression that nobody really cares. I mean there _many_ viable ways to have better configuration/build support for D. Jens
Re: CMake for D2 ready for testers
On 2/22/11 1:32 PM, Russel Winder wrote: Lua and Python seem, between them, to have about a 100% monopoly on the dynamic language plugin market, at least in the media software arena. IIRC, Naughty Dog, the people behind the Uncharted series, are using something like PLT Scheme, i.e. LISP, for their scripting needs (e.g. http://gameenginebook.com/gdc09-statescripting-uncharted2). Nevertheless, »about 100%« is probably right. David
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 15:33:48 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: I mainly push it as far as I need it because writing CMake code is no fun for me (and I do it in my free time). Thank you. Further I have the impression that nobody really cares. I mean there _many_ viable ways to have better configuration/build support for D. Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language. I'll try to help as soon as I become somewhat (more) familiar with Cmake and its 'language'. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
Gour wrote: On Tue, 22 Feb 2011 15:33:48 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Further I have the impression that nobody really cares. I mean there _many_ viable ways to have better configuration/build support for D. Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language. Yeah. My point is just that I don't know whether CMake will be the way to go. I mean it works but there are more elegant build tools in the pipeline. That's why I push it only as far as it needs to be. I'll try to help as soon as I become somewhat (more) familiar with Cmake and its 'language'. That would be very nice. So far we have quite decent support for * dmd (tested on Linux/Windows) * gdc (tested on Linux) Linking shared libraries on Linux using the C linker is also nice to have. This way you can use your favorite third-party C library in D. I also wanted to test it on Mac OS X but unfortunately I do not have access to a Mac. Looking into ldc may be also worthwhile. I did to a certain degree. But I never got a simple program to link. Jens
Re: CMake for D2 ready for testers
Jens Mueller wrote: Gour wrote: On Tue, 22 Feb 2011 15:33:48 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Further I have the impression that nobody really cares. I mean there _many_ viable ways to have better configuration/build support for D. Don't be discouraged...think about the future - having good build support is something like having vim/emacs editing-mode and (many) users simply expect to find one in the ecosystem of every serious language. Yeah. My point is just that I don't know whether CMake will be the way to go. I mean it works but there are more elegant build tools in the pipeline. That's why I push it only as far as it needs to be. I'll try to help as soon as I become somewhat (more) familiar with Cmake and its 'language'. That would be very nice. So far we have quite decent support for * dmd (tested on Linux/Windows) * gdc (tested on Linux) Linking shared libraries on Linux using the C linker is also nice to have. This way you can use your favorite third-party C library in D. I shouldn't have said nice to have. Because it sounds as if we want it but don't have it. It is already available thus allowing you to link with shared libraries. Jens
Re: CMake for D2 ready for testers
On 2/22/11 6:10 PM, Jens Mueller wrote: I also wanted to test it on Mac OS X but unfortunately I do not have access to a Mac. I don't have lots of time for experiments at the moment, but I'd be glad to help you out if you just need someone to run an existing set of tests on OS X or something. David
Re: CMake for D2 ready for testers
On Tue, 22 Feb 2011 18:10:11 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: Yeah. My point is just that I don't know whether CMake will be the way to go. I mean it works but there are more elegant build tools in the pipeline. That's why I push it only as far as it needs to be. Well, other, 'more elegant tools' are still immature, small userbase, not so many devs. On top of that, it's not certain on how many platforms they work, while seeing something like http://www.cdash.org/CDash/index.php?project=CMake is definitely impressive for me. That would be very nice. So far we have quite decent support for * dmd (tested on Linux/Windows) * gdc (tested on Linux) Cool. Soon, when I install (free)pcbsd, I can test on it. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
David Nadlinger wrote: On 2/22/11 6:10 PM, Jens Mueller wrote: I also wanted to test it on Mac OS X but unfortunately I do not have access to a Mac. I don't have lots of time for experiments at the moment, but I'd be glad to help you out if you just need someone to run an existing set of tests on OS X or something. That would be great. I want to fix issue http://code.google.com/p/cmaked2/issues/detail?id=8 For this you need to install CMake. There is a Universal Mac OSX Binary available at http://www.cmake.org/cmake/resources/software.html And then you can follow http://code.google.com/p/cmaked2/wiki/GettingStarted to install CMakeD. Then update the issue or send me the failing output. I hope it works out. Jens
Re: CMake for D2 ready for testers
On Sun, 5 Sep 2010 22:28:41 -0700 SK s...@metrokings.com wrote: Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) I played with Waf a bit and it has nice support for D. However, despite many contributors listed, it still seems to be mostly one-man-show which makes me a bit reluctant to use it over Cmake (SCons seems to be very slow without much progress), so I wonder what is the current status of the project? Any hope that D support will be applied in upstream? What about 64bit support in dmd2? Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Mon, 2011-02-21 at 11:31 +0100, Gour wrote: [ . . . ] 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. 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
On Mon, 21 Feb 2011 10:56:50 + Russel Winder rus...@russel.org.uk wrote: 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. 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 signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
Gour wrote: On Sun, 5 Sep 2010 22:28:41 -0700 SK s...@metrokings.com wrote: Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) I played with Waf a bit and it has nice support for D. However, despite many contributors listed, it still seems to be mostly one-man-show which makes me a bit reluctant to use it over Cmake (SCons seems to be very slow without much progress), so I wonder what is the current status of the project? Any hope that D support will be applied in upstream? I don't know about upstreaming it. Certainly it would be nice. But for doing so I need polish it further. It seems that not many people are using CMakeD and there seems to be less interest in it. But I used it for a word cloud I programed for a course (see here http://gitorious.org/wordcloud). The nice thing is that you can rely on CMake's modules. E.g. in the above example it was straightforward to let CMake make sure that the GD library it installed. That makes it very useful for integrating a C/C++ library. If you do not know already, the getting started guide is here http://code.google.com/p/cmaked2/wiki/GettingStarted According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu with CMake at least 2.8.2 and dmd at least 2.049. It should work on Windows as well. Some people have used it. Recently I added gdc support which works for me. But so far I haven't got any feedback from other users. What about 64bit support in dmd2? You mean support for building 64bit code with dmd2 using CMakeD? That should be fairly straightforward given that you just need to pass -m64 to dmd. I think by default it builds 32-bit even on a 64-bit machine. But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you. Recently I've been a bit distracted from CMakeD development since I stumbled over Gyp http://code.google.com/p/gyp/ and Premake http://industriousone.com/premake Both address similar needs like CMake but do not support D yet. Jens
Re: CMake for D2 ready for testers
On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote: [ . . . ] I don't know about upstreaming it. Certainly it would be nice. But for doing so I need polish it further. Can the code comprising the D support for CMake be packaged up so that it can be offerred to everyone direct from a DVCS repository? SCons and Waf have the tool concept to allow for this. CMake must have something analogous. People can then make use of the D support with their CMake without the necessity of it heading upstream -- though it would be good for that to happen eventually. It seems that not many people are using CMakeD and there seems to be less interest in it. But I used it for a word cloud I programed for a course (see here http://gitorious.org/wordcloud). The nice thing is that you can rely on CMake's modules. E.g. in the above example it was straightforward to let CMake make sure that the GD library it installed. That makes it very useful for integrating a C/C++ library. If you do not know already, the getting started guide is here http://code.google.com/p/cmaked2/wiki/GettingStarted According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu with CMake at least 2.8.2 and dmd at least 2.049. It should work on Windows as well. Some people have used it. Recently I added gdc support which works for me. But so far I haven't got any feedback from other users. Personally I prefer SCons and Waf over CMake, but would be happy to trial CMake and its D support. In fact the SCons tool I am trying to force myself to work on and the CMake D support may help each other by collaborating. 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? 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
Russel Winder wrote: On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote: [ . . . ] I don't know about upstreaming it. Certainly it would be nice. But for doing so I need polish it further. Can the code comprising the D support for CMake be packaged up so that it can be offerred to everyone direct from a DVCS repository? SCons and Waf have the tool concept to allow for this. CMake must have something analogous. People can then make use of the D support with their CMake without the necessity of it heading upstream -- though it would be good for that to happen eventually. Don't know how packaging is done in SCons/Waf. With CMakeD, you clone the repository, i.e. $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2 and $ cd cmaked2/cmaked $ mkdir build $ cd build $ cmake .. $ make install to install it. That will copy the necessary files into your CMake installation. I'll guess SCons/Waf offers something more than that. It seems that not many people are using CMakeD and there seems to be less interest in it. But I used it for a word cloud I programed for a course (see here http://gitorious.org/wordcloud). The nice thing is that you can rely on CMake's modules. E.g. in the above example it was straightforward to let CMake make sure that the GD library it installed. That makes it very useful for integrating a C/C++ library. If you do not know already, the getting started guide is here http://code.google.com/p/cmaked2/wiki/GettingStarted According to http://code.google.com/p/cmaked2/wiki/TestedPlatforms it was used on recent versions of Debian, ArchLinux, Gentoo, and Ubuntu with CMake at least 2.8.2 and dmd at least 2.049. It should work on Windows as well. Some people have used it. Recently I added gdc support which works for me. But so far I haven't got any feedback from other users. Personally I prefer SCons and Waf over CMake, but would be happy to trial CMake and its D support. In fact the SCons tool I am trying to force myself to work on and the CMake D support may help each other by collaborating. Yeah. I try to help, if I can. Don't hesitate asking. Though I have to admit I have almost no Python skills. I like Ruby more. It pleases my eyes and there seems to be only enough space for one scripting language in my head. What about 64bit support in dmd2? You mean support for building 64bit code with dmd2 using CMakeD? That should be fairly straightforward given that you just need to pass -m64 to dmd. I think by default it builds 32-bit even on a 64-bit machine. But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you. In one sense it is as easy as passing -m64 but there is also the issue of the list of libraries needed at link time -- or does the CMake stuff already pull in that information from dmd.conf? CMakeD just relies on dmd. But you're right it's a bit more complicated. It seems that on Linux CMake has no proper way of cross building a 32 bit/64 bit version. That kind of cross compiling does not seems to work. I would need to investigate further to find out whether it's a dmd problem. Usually I think for building a 32 bit C binary you just pass -m32 then the linker should search in ...lib32/. If you build a 64 bit binary it should search in ...lib64/. If you don't specify anything it's up to the compiler. CMake's task is just to check whether the dependent library is installed. I think at the moment it does not look in lib32/lib64 separately. In that sense it's support for cross compiling is weak. I may be wrong here. Recently I've been a bit distracted from CMakeD development since I stumbled over Gyp http://code.google.com/p/gyp/ and Premake http://industriousone.com/premake Both address similar needs like CMake but do not support D yet. Are these good enough to get traction compared to SCons, Waf, CMake, Autotools, Make, Ant, Maven, Gradle, Gant? This is a serious question not a troll. There is always space for a new, better build framework to take the community by storm, but on the other hand if they are just side shows then it dilutes effort and progress. I do not know yet. I think both of them are pretty weak regarding already available modules, i.e. files to find a specific dependency. Gyp is developed for building Chromium. They had a problem with SCons while migrating to it. They also wrote in what regard CMake didn't work out for them http://code.google.com/p/gyp/wiki/GypVsCMake I like premake for it's readability see http://industriousone.com/sample-script and it's all Lua. Though I'm not sure whether I can keep two scripting languages in my head. But Lua seems to be very simple. Jens
Re: CMake for D2 ready for testers
On Mon, 21 Feb 2011 12:40:11 +0100 Jens Mueller jens.k.muel...@gmx.de wrote: I don't know about upstreaming it. Certainly it would be nice. But for doing so I need polish it further. OK. It seems that not many people are using CMakeD and there seems to be less interest in it. I believe many are waiting that D(2) become consolidated a bit, 64bit port etc. At least, I'm the one of them. :-) But I assume this is going to change once 64-bit is stable. If I find some time I will build the above word cloud example for 64-bit and report here, if that helps you. I'll take a look tomorrow closer look at CMakeD. Recently I've been a bit distracted from CMakeD development since I stumbled over Gyp http://code.google.com/p/gyp/ and Premake http://industriousone.com/premake Both address similar needs like CMake but do not support D yet. They look interesting, but I'm sure they cannot replace CMake and therefore hope D will become 1st class citizen in the CMake country. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Sat, 9 Oct 2010 16:48:15 +0200 Gour == Gour D. g...@atmarama.net wrote: Gour Rationale? I forgot to add: x) deps are determined by hash and not by timestamps Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Fri, Oct 8, 2010 at 12:41 PM, Jens Mueller jens.k.muel...@gmx.de wrote: I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. My sentiments exactly. Discussing the beauties of a particular build system is all well and good, but what really matters are the warts that emerge only after you're a long way into a big project.
Re: CMake for D2 ready for testers
On Fri, 2010-10-08 at 22:25 +0200, Gour D. wrote: On Fri, 08 Oct 2010 17:26:25 +0100 Russel == Russel Winder rus...@russel.org.uk wrote: 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. 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. 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. 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote: Do you recommend to learn use CMake instead of using tools like Xfbuild (I'm interested for D project and, so far, was accustomed to Haskell's Cabal, so looking for similar experience.) For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy. I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration. Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. SCons is used by Intel for most of their software products, especially the parallel tools suite, also by id Games for all their products. Simply listing users of a product is a pissing contest and not at all helpful. If you choose a tool that many others have chosen and are happy with then fine, you get the comfort of not being on your own -- and that is a good thing. However, an individuals or organizations actual needs may mean that using something not chosen by the herd is far more beneficial. All these arguments happen when choosing version control systems as well as build systems. I never used this but CMake has generators for Visual Studio and through the Makefile Generators you can integrate it in CodeBlocks and Eclipse. Don't know how important this is. I live happily with the generated Makefiles. SCons can likewise generate Visual Studio project files. SCons can be used directly in Eclipse so no need for Makefile generation. Coming back to the original question. I can recommend CMake especially if one plans to do C and C++ programming. For D we (Steve, Dean and I) are trying to improve the support. Fixing Mac OSX is next on my list. I have no doubt that CMake is a viable alternative for some people/organizations in some contexts. As a replacement for Autotools, then compared to Waf it comes third for me behind second place SCons. I generally prefer SCons or Waf -- Waf is originally a fork of SCons but now is its own thing, and is aimed at being an Autotools replacement (get source download and build on this machine type model). SCons is better at handling the sort of situation I have: source repository shared by many platforms all needing builds in situ. Waf is somewhat faster than SCons. For my sins I am peripherally involved in the SCons development community, and I at some time elected myself as the maintainer of the D plugin -- the plugin as D shipped until recently with SCons assumed D 1.0 and I am only using D 2.0. So when I asked who could fix the problem, the answer came back you can, so I did, sort of :-) It would be good if there was a community of D/SCons users so as to get some headway on making the SCons D plugin as good as it needs to be. I have to admit I neither know Scons nor Waf. Maybe these are superior. They're Python-based, right? I'll guess that makes them favorable for Python programmers. SCons and Waf are both Python systems that have an internal DSL for describing the build. Both have the classic two phase operation: read the files and build the DAG describing the project and build; analyse the filestore and spawn tasks in order to reconcile the actual filestore with the required filestore. (Actually 'filestore' is a variable here, you an target things other than the filestore, but its usually the filestore being processed.) Using Python (or any other dynamic language I would suspect, cf Rake, Rant using Ruby) is a big win, certainly over m4 macros. CMake has its own language which is part way to being Lisp but has lots of quirks and idiosyncrasies such that if they had just used a Lisp interpreter, things would be a lot better. On top of my head some things I find nice in CMake. Just curious whether Scons/Waf have similar features. * Find Google Test/other libraries (if supported) in one line: find_package(GTest REQUIRED) Waf and SCons can both do this but it is not packaged as a one liner in this form. The issue is how the dependencies are packaged up in order to create. CMake has one route, Waf one route and SCons a slightly different route. CMake looks good on this point but Waf and SCons are not poor in comparison. * Tight integration for testing and packaging (ctest, cpack) Somewhat unfair to appear to name CTest and CPack as requirements as they are are Kitware products integrated into CMake ;-) Waf and SCons both have infrastructure for supporting tests, they are just called something different than CTest and CPack * Publishing build/test results Isn't that the job of the continuous integration server? * No
Re: CMake for D2 ready for testers
On Sat, 2010-10-09 at 00:16 +0200, Gour D. wrote: [ . . . ] Here is the waf list: http://code.google.com/p/waf/wiki/ProjectsUsingWaf The SCons list is at http://www.scons.org/wiki/SconsProjects but I think there are some big users who haven't signed up there. Intel for one who use SCons with their huge modules support system Parts that is a bolt on to SCons. So user lists are only as good as the marketing department of the product and Waf and SCons have none whilst Kitware does! [ . . . ] Waf really looks good and, afaics, it's more extensible than Scons. I would put them both the same. The Waf plugin API is though a little more sophisticated. Here is the table with some comparisons: 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,. [ . . . ] Only dist for tarballs, afaict. I thought Waf did zipfiles as well, SCons certainly does both. Is there a need for anything else beyond those? Jens * Publishing build/test results No idea. Depends what is meant. If Waf and SCons don't have it then a few minutes and a Python plugin later you have the facility. Jens * No dependencies besides a C++ compiler for installation. This is one advantage of waf that it only requires ~80K python script which is, usually, distributed with the sources. SCons can do the same but this is rarely done where it is the standard form for Waf. This shows the different philosophies behind Waf and SCons and consequently can be the deciding factor often. [ . . . ] In any case, it's interesting and we'll put it on our evaluation-list. Happy evoluation :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
Gour D. wrote:
On Fri, 8 Oct 2010 21:41:55 +0200
Jens == Jens Mueller jens.k.muel...@gmx.de wrote:
Jens Coming back to the original question. I can recommend CMake
Jens especially if one plans to do C and C++ programming. For D we
Jens (Steve, Dean and I) are trying to improve the support. Fixing Mac
Jens OSX is next on my list.
My primary interest is D and developing on Linux, although we want our
app to run on Mac Windows as well (hopefully using QtD).
With CMake you can check whether Qt is installed on the system. There is
a FindQt.cmake.
Jens I have to admit I neither know Scons nor Waf. Maybe these are
Jens superior. They're Python-based, right? I'll guess that makes them
Jens favorable for Python programmers.
Waf really looks good and, afaics, it's more extensible than Scons.
Here is the table with some comparisons:
http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems
They have very good documentation. Something that's not the case for
CMake. With CMake you have to google a lot. Thankfully that's mainly
needed if you dive into into the internals. Writing a simple
CMakeLists.txt is a matter of minutes. I hope I'm not too biased here
because I've been using it for almost 2 years.
Jens On top of my head some things I find nice in CMake. Just curious
Jens whether Scons/Waf have similar features.
I'm not at all familiar with waf, just read a bit about it and here is
the feature list:
http://code.google.com/p/waf/
and here is the 'book':
http://freehackers.org/~tnagy/wafbook160p3/
Wow. They have excellent documentation.
Jens * Find Google Test/other libraries (if supported) in one line:
Jens find_package(GTest REQUIRED)
I see something like:
ctx.find_program('touch', var='TOUCH')
Only finds a program, right? I'd like to find a library. I.e. I need the
path to the header files and the library files. I'll guess there is
something like find_file.
Jens * Tight integration for testing and packaging (ctest, cpack)
Only dist for tarballs, afaict.
I do not know how important this whole Windows integration is, but with
CMake you can generate a Windows installer.
Together with Visual Studio support it's a good choice if Windows is
your main client. Could be the reason why CMake is used so often.
Jens * No dependencies besides a C++ compiler for installation.
This is one advantage of waf that it only requires ~80K python script
which is, usually, distributed with the sources.
You need to have python installed. I have no feeling how many system
have python installed. But probably more than CMake.
Jens * Valgrind/Purify integration
Considering Samba uses Waf, Google returned:
http://wiki.samba.org/index.php/Debugging_individual_tests
Interesting.
Moreover, since the system uses full-featured programming language,
probably there are no restriction what can be done...
In any case, it's interesting and we'll put it on our evaluation-list.
Can you keep me informed about the result? Just curious which features
influenced your final decision.
Jens
Re: CMake for D2 ready for testers
On Sat, 2010-10-09 at 12:06 +0200, Jens Mueller wrote:
[ . . . ]
With CMake you can check whether Qt is installed on the system. There is
a FindQt.cmake.
Waf can do this sort of thing simply as well, especially via pgk-config
if available. SCons is a little more clumsy but it is there and usable.
Basically I think they are all the same on this sort of point in that
there is a tick in the box.
[ . . . ]
They have very good documentation. Something that's not the case for
CMake. With CMake you have to google a lot. Thankfully that's mainly
needed if you dive into into the internals. Writing a simple
CMakeLists.txt is a matter of minutes. I hope I'm not too biased here
because I've been using it for almost 2 years.
I agree that just writing CMakeLists.txt is not hard if you have a
straightforward project. But I found the poor documentation of CMake a
barrier a couple of years back when I had a non-standard build.
To be honest I don't think the Waf documentation is that good either.
In far too many places presentation is Waf implementation oriented and
assumes knowledge of the source code. SCons documentation is not that
great either. The user guide is a bit too superficial, but the manual
page is authoritative, just lacking in examples. The wikis and
especially the mailing lists are the things that mean Waf and SCons
users have few problems.
[ . . . ]
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.
[ . . . ]
I do not know how important this whole Windows integration is, but with
CMake you can generate a Windows installer.
Together with Visual Studio support it's a good choice if Windows is
your main client. Could be the reason why CMake is used so often.
I suspect CMake is ahead of Waf and SCons on this, but there are
external tools that can be use, and I am fairly sure they are usable
trivially from Waf and SCons.
[ . . . ]
You need to have python installed. I have no feeling how many system
have python installed. But probably more than CMake.
I suspect that Windows is the only system that does not now ship a
version of Python as standard.
[ . . . ]
In any case, it's interesting and we'll put it on our evaluation-list.
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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
On 10/9/10 11:40 AM, Russel Winder wrote: Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. If you accuse someone of not basing the decision »on a proper study«, I am sure you have some references on hand for that? Usually, a lot of decisions regarding KDE is made based on a meritocracy-like system, »nasty politiking« isn't something I'd expect to see very often… This article[1] from the KDE build system maintainer paints quite a different picture. It seems that they indeed tried to use SCons, even actively worked at the SCons extension bksys (as in »Build Kde System«). Apparently, however, a number of not quite easily resolvable problems popped up (including missing support by the SCons upstream), so they ditched SCons/bksys and went with CMake. Later on, somebody decided to do a complete rewrite of bksys/SCons, because some of the problems were apparently related so closely to the internals of SCons that there was no other feasible way of fixing them. I agree that the macro language of CMake is probably not the most beautiful solution (a port to Lua is planned, IIRC), but it has been proven to work almost flawlessly on huge projects. Even for the build system cracks of the KDE project, autotools was a constant source of trouble back when they used it – CMake apparently has solved most of the problems, while SCons/bksys failed at it. [1] http://lwn.net/Articles/188693/
Re: CMake for D2 ready for testers
Russel Winder wrote: On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote: For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy. I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration. Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. SCons is used by Intel for most of their software products, especially the parallel tools suite, also by id Games for all their products. Simply listing users of a product is a pissing contest and not at all helpful. If you choose a tool that many others have chosen and are happy with then fine, you get the comfort of not being on your own -- and that is a good thing. However, an individuals or organizations actual needs may mean that using something not chosen by the herd is far more beneficial. My point is only that CMake works for big projects. Which makes a strong argument. If you run into a problem you can very likely check out how they did it. However they ended up with it, it seems to do its job. But of course if other tools can handle this equally good you need to go beyond that. I never used this but CMake has generators for Visual Studio and through the Makefile Generators you can integrate it in CodeBlocks and Eclipse. Don't know how important this is. I live happily with the generated Makefiles. SCons can likewise generate Visual Studio project files. SCons can be used directly in Eclipse so no need for Makefile generation. That's nice. I have to admit I neither know Scons nor Waf. Maybe these are superior. They're Python-based, right? I'll guess that makes them favorable for Python programmers. SCons and Waf are both Python systems that have an internal DSL for describing the build. Both have the classic two phase operation: read the files and build the DAG describing the project and build; analyse the filestore and spawn tasks in order to reconcile the actual filestore with the required filestore. (Actually 'filestore' is a variable here, you an target things other than the filestore, but its usually the filestore being processed.) Using Python (or any other dynamic language I would suspect, cf Rake, Rant using Ruby) is a big win, certainly over m4 macros. CMake has its own language which is part way to being Lisp but has lots of quirks and idiosyncrasies such that if they had just used a Lisp interpreter, things would be a lot better. I agree. It's not a nice solution. Maybe they are just known because a company supports it and puts some effort into it. But in the long run maybe others will take over because of better design. On top of my head some things I find nice in CMake. Just curious whether Scons/Waf have similar features. * Find Google Test/other libraries (if supported) in one line: find_package(GTest REQUIRED) Waf and SCons can both do this but it is not packaged as a one liner in this form. The issue is how the dependencies are packaged up in order to create. CMake has one route, Waf one route and SCons a slightly different route. CMake looks good on this point but Waf and SCons are not poor in comparison. How do you do this with Waf/Scons? Best solution to me is: Somebody writes a module for finding a library and this module is distributed with the tool. The user only needs to include the module. * Tight integration for testing and packaging (ctest, cpack) Somewhat unfair to appear to name CTest and CPack as requirements as they are are Kitware products integrated into CMake ;-) Waf and SCons both have infrastructure for supporting tests, they are just called something different than CTest and CPack Just wanted to mention that you can test and package your software. I'm not here to disqualify any other tool. Just want to say what you can do with CMake and what seems important to me. * Publishing build/test results Isn't that the job of the continuous integration server? Depends. I know of a C++ project that uses CMake. Before they ship a new release they need to make sure that the building and testing pass. On their mailing list the maintainer announces that she likes to ship a new version and says something like: We want to support these compilers and those platforms. Since each developer has a different development setup they just run the tests locally and publish them to a central board. One after the other the developers post their results. I find this quite nice for distributed/Open Source development. Decoupling the testing and publishing. Of course you can
Re: CMake for D2 ready for testers [ drifting off topic ]
On Sat, 2010-10-09 at 13:01 +0200, klickverbot wrote: 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. 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. 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. 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: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
On Sat, 09 Oct 2010 10:56:45 +0100 Russel == Russel Winder wrote: Russel I thought Waf did zipfiles as well, SCons certainly does both. Correct. Default in Waf is bzip2, with the support for gzip zip. Russel Is there a need for anything else beyond those? Not really. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Sat, 09 Oct 2010 10:19:50 +0100 Russel == Russel Winder wrote: Russel Personally I am principally an Emacs and command line person so Russel IDE is low on my agenda, though I use SCons as my build tool Russel when using Eclipse/CDT. SCons has the capability if creating Russel Visual Studio project files -- and we have to be honest here Russel and say that most C and C++ coding happens in Visual Studio -- Russel and whilst I don't think there is currently CodeBlock support Russel it would be relatively easy to put it in place. I am fairly Russel sure Waf has some facilities in this area. I also use Emacs, but might use CodeBlocks if we the members of the team agree on it. There is plan to support creating Codeblock files in waf. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Sat, 9 Oct 2010 12:06:46 +0200
Jens == Jens Mueller wrote:
Jens Wow. They have excellent documentation.
Indeed. I'm just reading it.
Jens Only finds a program, right? I'd like to find a library. I.e. I
Jens need the path to the header files and the library files. I'll
Jens guess there is something like find_file.
There is, e.g. ctx.find_file('fstab', ['/opt', '/etc'])
Jens I do not know how important this whole Windows integration is,
Jens but with CMake you can generate a Windows installer.
That's missing in Waf.
Jens Together with Visual Studio support it's a good choice if Windows
Jens is your main client. Could be the reason why CMake is used so
Jens often.
In my case, I'll develop on Linux.
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
signature.asc
Description: PGP signature
Re: CMake for D2 ready for testers
On Sat, 09 Oct 2010 11:30:44 +0100 Russel == Russel Winder wrote: 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 signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Sun, 5 Sep 2010 22:28:41 -0700 SK == SK s...@metrokings.com wrote: SK Why labor over buggy Makefiles when you could be laboring over buggy SK CMake files at a much more productive level of abstraction? :o) Do you recommend to learn use CMake instead of using tools like Xfbuild (I'm interested for D project and, so far, was accustomed to Haskell's Cabal, so looking for similar experience.) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
On Fri, 2010-10-08 at 16:34 +0200, Gour D. wrote: Do you recommend to learn use CMake instead of using tools like Xfbuild (I'm interested for D project and, so far, was accustomed to Haskell's Cabal, so looking for similar experience.) For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy. I generally prefer SCons or Waf -- Waf is originally a fork of SCons but now is its own thing, and is aimed at being an Autotools replacement (get source download and build on this machine type model). SCons is better at handling the sort of situation I have: source repository shared by many platforms all needing builds in situ. Waf is somewhat faster than SCons. For my sins I am peripherally involved in the SCons development community, and I at some time elected myself as the maintainer of the D plugin -- the plugin as D shipped until recently with SCons assumed D 1.0 and I am only using D 2.0. So when I asked who could fix the problem, the answer came back you can, so I did, sort of :-) It would be good if there was a community of D/SCons users so as to get some headway on making the SCons D plugin as good as it needs to be. Isn't Cabal a dependency resolution system rather than a build system? i.e. Cabal sits in the same sort of position as Apt, Ivy, the Maven dependency resolution system, rather than being the equivalent of Ant +Ivy or Maven as a whole. (C, C++, Fortran, and D seem to be less interested in depndency resolution than the JVM-based milieu of Java, Scala, Groovy, Clojure, etc. hence the Ant/Maven perspective.) I also tried starting a Haskell SCons plugin but haven't really got it moving properly as yet. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake for D2 ready for testers
On Fri, 08 Oct 2010 17:26:25 +0100 Russel == Russel Winder rus...@russel.org.uk wrote: 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 signature.asc Description: PGP signature
Re: CMake for D2 ready for testers
Do you recommend to learn use CMake instead of using tools like Xfbuild (I'm interested for D project and, so far, was accustomed to Haskell's Cabal, so looking for similar experience.) For C, C++, Fortran, and hence D, I personally find CMake awkward and clumsy. I also think CMake isn't that shiny. But you can get the job done once you're familiar with it. And it has been adopted by some big projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). That should be put into consideration. I never used this but CMake has generators for Visual Studio and through the Makefile Generators you can integrate it in CodeBlocks and Eclipse. Don't know how important this is. I live happily with the generated Makefiles. Coming back to the original question. I can recommend CMake especially if one plans to do C and C++ programming. For D we (Steve, Dean and I) are trying to improve the support. Fixing Mac OSX is next on my list. I generally prefer SCons or Waf -- Waf is originally a fork of SCons but now is its own thing, and is aimed at being an Autotools replacement (get source download and build on this machine type model). SCons is better at handling the sort of situation I have: source repository shared by many platforms all needing builds in situ. Waf is somewhat faster than SCons. For my sins I am peripherally involved in the SCons development community, and I at some time elected myself as the maintainer of the D plugin -- the plugin as D shipped until recently with SCons assumed D 1.0 and I am only using D 2.0. So when I asked who could fix the problem, the answer came back you can, so I did, sort of :-) It would be good if there was a community of D/SCons users so as to get some headway on making the SCons D plugin as good as it needs to be. I have to admit I neither know Scons nor Waf. Maybe these are superior. They're Python-based, right? I'll guess that makes them favorable for Python programmers. On top of my head some things I find nice in CMake. Just curious whether Scons/Waf have similar features. * Find Google Test/other libraries (if supported) in one line: find_package(GTest REQUIRED) * Tight integration for testing and packaging (ctest, cpack) * Publishing build/test results * No dependencies besides a C++ compiler for installation. * Continuous Integration watching subversion repository * Valgrind/Purify integration Jens
Re: CMake for D2 ready for testers
On Fri, 8 Oct 2010 21:41:55 +0200
Jens == Jens Mueller jens.k.muel...@gmx.de wrote:
Jens I also think CMake isn't that shiny. But you can get the job done
Jens once you're familiar with it. And it has been adopted by some big
Jens projects: Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see
Jens http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake).
Jens That should be put into consideration.
Here is the waf list:
http://code.google.com/p/waf/wiki/ProjectsUsingWaf
Jens I never used this but CMake has generators for Visual Studio and
Jens through the Makefile Generators you can integrate it in
Jens CodeBlocks and Eclipse. Don't know how important this is. I live
Jens happily with the generated Makefiles.
in waf's TODO I found some similar items, although not labelled as
high-priority:
+ IDE file generator (msvc, codeblocks)
+ CMake file interpreter
Jens Coming back to the original question. I can recommend CMake
Jens especially if one plans to do C and C++ programming. For D we
Jens (Steve, Dean and I) are trying to improve the support. Fixing Mac
Jens OSX is next on my list.
My primary interest is D and developing on Linux, although we want our
app to run on Mac Windows as well (hopefully using QtD).
Jens I have to admit I neither know Scons nor Waf. Maybe these are
Jens superior. They're Python-based, right? I'll guess that makes them
Jens favorable for Python programmers.
Waf really looks good and, afaics, it's more extensible than Scons.
Here is the table with some comparisons:
http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems
Jens On top of my head some things I find nice in CMake. Just curious
Jens whether Scons/Waf have similar features.
I'm not at all familiar with waf, just read a bit about it and here is
the feature list:
http://code.google.com/p/waf/
and here is the 'book':
http://freehackers.org/~tnagy/wafbook160p3/
Jens * Find Google Test/other libraries (if supported) in one line:
Jens find_package(GTest REQUIRED)
I see something like:
ctx.find_program('touch', var='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
signature.asc
Description: PGP signature
Re: CMake for D2 ready for testers
SK s...@metrokings.com wrote in message news:mailman.113.1283750971.858.digitalmar...@puremagic.com... Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform make maker. Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Interesting, I had no idea cmake generated makefiles. (For that matter, I had no idea cmake was anything more that yet another version of make, like nmake, GNU make, etc.) Not to be contentious, just curious about the design philosophy behind cmake: Why is it a layer on-top of make at all instead of just bypassing the antiquated make altogether? GNU autotools does the same thing (ie, fix make by just adding more layers on top of it), and that always struck me as silly. Is there some particular reason for this approach?
Re: CMake for D2 ready for testers
On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote: SK s...@metrokings.com wrote in message news:mailman.113.1283750971.858.digitalmar...@puremagic.com... Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform make maker. Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Interesting, I had no idea cmake generated makefiles. (For that matter, I had no idea cmake was anything more that yet another version of make, like nmake, GNU make, etc.) Not to be contentious, just curious about the design philosophy behind cmake: Why is it a layer on-top of make at all instead of just bypassing the antiquated make altogether? GNU autotools does the same thing (ie, fix make by just adding more layers on top of it), and that always struck me as silly. Is there some particular reason for this approach? cmake can generate a variety of different build system files, including both makefiles and visual studio project files. So, you can use the same cmake files to generate build stuff for multiple OSes. Also, it's a lot cleaner and simpler to set a lot of stuff up then it is in makefiles. When KDE was using autotools, they pretty much couldn't do a Windows version because it would have been too disgusting to alter them as necessary. However, after having switched to cmake, they could do it. I haven't used it a whole lot at this point, so I'm not sure of all of the ins and outs, but it's a lot more pleasant to deal with than makefiles, and it's a lot more flexible. - Jonathan M Davis
Re: CMake for D2 ready for testers
Jonathan M Davis jmdavisp...@gmail.com wrote in message news:mailman.114.1283754439.858.digitalmar...@puremagic.com... On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote: SK s...@metrokings.com wrote in message news:mailman.113.1283750971.858.digitalmar...@puremagic.com... Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform make maker. Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Interesting, I had no idea cmake generated makefiles. (For that matter, I had no idea cmake was anything more that yet another version of make, like nmake, GNU make, etc.) Not to be contentious, just curious about the design philosophy behind cmake: Why is it a layer on-top of make at all instead of just bypassing the antiquated make altogether? GNU autotools does the same thing (ie, fix make by just adding more layers on top of it), and that always struck me as silly. Is there some particular reason for this approach? cmake can generate a variety of different build system files, including both makefiles and visual studio project files. So, you can use the same cmake files to generate build stuff for multiple OSes. Also, it's a lot cleaner and simpler to set a lot of stuff up then it is in makefiles. When KDE was using autotools, they pretty much couldn't do a Windows version because it would have been too disgusting to alter them as necessary. However, after having switched to cmake, they could do it. I haven't used it a whole lot at this point, so I'm not sure of all of the ins and outs, but it's a lot more pleasant to deal with than makefiles, and it's a lot more flexible. Well, I guess what I mean is, compared to something like SCons, Rake or A-A-P. Those tools, like cmake, handle cross-platform no problem while providing far saner syntax than traditional make. But unline cmake, they don't have any reliance on traditional make even on unix. Granted, they don't generate IDE project files, but my initial impression of that is importing information *from* IDE project files would seem to be a more practical approach. From what tiny bit I read on the site (it seemed suprisingly hard to find the documentation on the site, but maybe that was just me), it does seem heavily C/C++ centric, and so it looks like it may be able to handle different C/C++ compilers fairly well. By contrast, SCons and Rake, as far as I can tell, don't seem to have any specific provisions for abstracting different compilers for a single language (though A-A-P does try to do that). So maybe that has something to do with it? Again, I hope I'm not coming across as challenging the usefulness or quality of cmake - that's not my intent. Just curious about why it chooses not to ditch traditional-make entierly like some of the other build systems do.
Re: CMake for D2 ready for testers
On Monday 06 September 2010 01:53:55 Nick Sabalausky wrote: Well, I guess what I mean is, compared to something like SCons, Rake or A-A-P. Those tools, like cmake, handle cross-platform no problem while providing far saner syntax than traditional make. But unline cmake, they don't have any reliance on traditional make even on unix. Granted, they don't generate IDE project files, but my initial impression of that is importing information *from* IDE project files would seem to be a more practical approach. From what tiny bit I read on the site (it seemed suprisingly hard to find the documentation on the site, but maybe that was just me), it does seem heavily C/C++ centric, and so it looks like it may be able to handle different C/C++ compilers fairly well. By contrast, SCons and Rake, as far as I can tell, don't seem to have any specific provisions for abstracting different compilers for a single language (though A-A-P does try to do that). So maybe that has something to do with it? Again, I hope I'm not coming across as challenging the usefulness or quality of cmake - that's not my intent. Just curious about why it chooses not to ditch traditional-make entierly like some of the other build systems do. I really have no idea why cmake doesn't ditch makefiles. It's probably because it's intended as a wrapper for a build system as opposed to being the build system itself, but I don't know. As for the documentation, I thought that it was extremely poor overall, so I got the book. They really should improve their documentation. - Jonathan M Davis
Re: CMake for D2 ready for testers
Haven't tried it yet, but thank you very much! This is something I missed a lot :-) LMB SK Wrote: Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform make maker. Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Cheers, -steve
Re: CMake for D2 ready for testers
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.
Re: CMake for D2 ready for testers
On Mon, Sep 6, 2010 at 1:53 AM, Nick Sabalausky a...@a.a wrote: Jonathan M Davis jmdavisp...@gmail.com wrote in message news:mailman.114.1283754439.858.digitalmar...@puremagic.com... On Sunday 05 September 2010 22:55:58 Nick Sabalausky wrote: Not to be contentious, just curious about the design philosophy behind cmake: Why is it a layer on-top of make at all instead of just bypassing the antiquated make altogether? GNU autotools does the same thing (ie, fix make by just adding more layers on top of it), and that always struck me as silly. Is there some particular reason for this approach? cmake can generate a variety of different build system files, including both makefiles and visual studio project files. So, you can use the same cmake files to generate build stuff for multiple OSes. Also, it's a lot cleaner and simpler to set a lot of stuff up then it is in makefiles. When KDE was using autotools, they pretty much couldn't do a Windows version because it would have been too disgusting to alter them as necessary. However, after having switched to cmake, they could do it. I haven't used it a whole lot at this point, so I'm not sure of all of the ins and outs, but it's a lot more pleasant to deal with than makefiles, and it's a lot more flexible. Well, I guess what I mean is, compared to something like SCons, Rake or A-A-P. Those tools, like cmake, handle cross-platform no problem while providing far saner syntax than traditional make. But unline cmake, they don't have any reliance on traditional make even on unix. Granted, they don't generate IDE project files, but my initial impression of that is importing information *from* IDE project files would seem to be a more practical approach. From what tiny bit I read on the site (it seemed suprisingly hard to find the documentation on the site, but maybe that was just me), it does seem heavily C/C++ centric, and so it looks like it may be able to handle different C/C++ compilers fairly well. By contrast, SCons and Rake, as far as I can tell, don't seem to have any specific provisions for abstracting different compilers for a single language (though A-A-P does try to do that). So maybe that has something to do with it? Again, I hope I'm not coming across as challenging the usefulness or quality of cmake - that's not my intent. Just curious about why it chooses not to ditch traditional-make entierly like some of the other build systems do. Hi Nick - Yes, it's certainly a debatable question but I can't offer special insight. Skipping my own long and checkered experiences with build systems, I'll say that CMake has been the first to reach the lofty level of satisfactory. Some related reading: Why KDE switched to cmake: http://lwn.net/Articles/188693 The CMake documentation is OK. 90% of the time I look here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html The command line --help is extensive. Regards, -steve
Re: CMake for D2 ready for testers
I will definitely be checking this out. I've used CMake with C++ for quite a large project and it's been very good at of getting the done without being the infinite tower of turtles on turtles that autotools seems to be. (I never managed to learn autotools so perhaps they don't seem as bad once you're using them.) On 06/09/10 06:28, SK wrote: Why labor over buggy Makefiles when you could be laboring over buggy CMake files at a much more productive level of abstraction? :o) With excellent help from Jens Mueller and Dean Calver, CMake for D2 now passes our small suite of unit tests on both Windows and Linux. Our tests include mixed C-D applications and libraries. We tested with CMake 2.8.2 and DMD 2.048. We'd appreciate if a few hardy souls were willing to take a test drive. Check it out here: http://code.google.com/p/cmaked2. Please report problems on the cmaked2 tracker rather than here. Unfortunately, we have not had an opportunity to test on Mac OS's. Briefly, CMake is a cross-platform make maker. Many people find CMake more attractive than traditional Makefiles or Autotools, especially for large projects. You can find more information here: http://www.cmake.org. Cheers, -steve
