CMake for D2 ready for testers

[Russel Winder]

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.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110222/2a58c887/attachment.pgp>