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