Re: [dev] [OFFTOPIC] Recommended meta-build system

I have been using make(1) and acr(1) for most of my projects for a long
while
and Im pretty happy with them. But I have to agree that make lacks so many
things and it is bloated enought to think on moving to mk(1).

Some projects like perl use perl (miniperl) to generate makefiles from
simplest
template files, so the makefile maintainance is easier.

For me I used to write makefiles manually (not using any GNU auto-shit),
I have
started to write 'amr' like a minimal automake-compatible replacement
together
with 'acr' (auto conf replacement) which is already an usable solution.

AMR is quite broken atm and works only for simple test cases, but ACR is
probably
the best alterative for autoconf. It generates a 15KB configure script
with compatible
posix shellscript instead of the common 300K from GNU, and yeah its
readable.
I have used ACR for building on solaris, *BSD, Linux and cygwin/mingw32
and I'm
happy with it.

In radare2[2] I used acr to check and configure the build system for a
prefix, check
dependencies, system, bitsize, plugins, compilation options, etc.. and
then it generates
two makefiles which imports some .mk files containing the rules for the
rest of modules.

I think that if you have a big project and you have to maintain it by
makefiles is better
to group common blocks by same rules by just configuring those elements
with few
variables used by the .mk files to set up some rules or others depending
on the module
type. or just including a different .mk file. This will make your
project makefiles be 3-4 lines
long and much more maintainable. Check the radare2 hg repo if you are
interested on
this.

If you are looking for ACR use examples, check any of the other projects
in hg.youterm.com
or just see the one in radare.

PD: Is there any tutorial or good documentation about how to use mk?
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. 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/
>
>
Received on Mon Jan 25 2010 - 15:40:52 UTC