On Mon, Jan 25, 2010 at 4:40 PM, pancake <panc...@youterm.com> wrote: > PD: Is there any tutorial or good documentation about how to use mk?
http://doc.cat-v.org/plan_9/4th_edition/papers/mk http://doc.cat-v.org/plan_9/4th_edition/papers/mkfiles > because > 'make' is > nice, but its too shell dependend and this forces the execution to fork for > most of basic > operations slowing down the execution and there are many other things that > makes > 'make' innefficient in some situations. If any of those things are a concern, you are clearly doing things *completely wrong*. uriel > But I dont know if mk will be better > for that. > > About cmake. i never liked because its c++ and it is not everywhere (you > have to > explicitly install it), and that's a pain in the ass for distributing apps. > I like to depend on > as less things as possible. > > Another build system I tried was 'waf'[3], and I got really exhausted of > changing the > rule files to match the last version of waf (they changed the API many times > (at least > when I was using it). The good thing of waf is that its python ( i dont like > python, but > its everywhere) so there's no limitation on shell commands and forks, and > the > configure/make stages are done nicer than in make(1) or autotools (they only > install > files that are diffeerent in timestamp for example) resulting in a faster > compilation > and installation. > > Another good thing of waf is that it can be distributed with the project, so > you dont > need to install waf to compile the project. Only depends on python which is > something > you can sadly find in all current distributions :) > > [1] http://hg.youterm.com/acr > [2] http://radare.org > > Armando Di Cianno wrote: >> >> David, >> >> I worked with the people at Kitware, Inc. for a while (here in >> beautiful upstate New York), and they wrote and maintain CMake [1]. I >> believe KDE, IIRC, has used CMake for a while now (which is at least a >> testament to the complexity it can handle). >> >> IMHO, CMake does not have a great syntax, but it's easy to learn and >> write. Again, IMHO, orders of magnitude easier to understand than GNU >> auto*tools -- although it is a bit pedantic (e.g. closing if branches >> with the condition to match the opening). >> >> However, for all its faults, it's *really* easy to use, and the >> for-free GUIs (ncurses or multi-platforms' GUIs), are icing on the >> cake. The simple ncurses GUI is nice to have when reconfiguring a >> project -- it can really speed things up. >> >> >>> >>> stuff like "has vsnprintf?" that configure deals with.) In addition, >>> it'd be nice to be able to have options like "debugging", "release", >>> "grof-compiled", etc, similar to procesor specification. >>> It would be preferrable if all >>> object files and executables could coexist (because it's a C++ >>> template heavy >>> >> >> CMake can do all this for you, and it works great with C and C++ >> projects (really, that's the only reason one would use it). >> >> 2¢, >> __armando >> >> [1] http://cmake.org/ >> >> > > >
