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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
