CMake for D2 ready for testers

[Jens Mueller]

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