CMake for D2 ready for testers

Jens Mueller jens.k.mueller at gmx.de
Tue Feb 22 03:07:13 PST 2011


Gour wrote:
> On Mon, 21 Feb 2011 21:22:54 +0100
> Jens Mueller <jens.k.mueller at 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 at 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


More information about the Digitalmars-d mailing list