[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix #1133

From: Jörg F. Wittenberger
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Fri, 04 Jul 2014 09:51:03 +0200
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:24.0) Gecko/20100101 Icedove/24.5.0

+1 …

Am 03.07.2014 20:23, schrieb Aleksej Saushev:
In general, CMake doesn't solve any real problem of Make. In some aspects
it is a step back even. CMake is mostly equivalent to Make + some autotools.

Plus: this mixing of make's job with the configuration management is what I perceive as the real (technical) disadvantage of cmake.

The only Make's problem it does solve is the problem of divergent dialects.
CMake has only one. But that's triviality. We employ the same solution
by requiring bmake and ignoring all other dialects.

For quite a long time I managed to use the "original" make dialect exclusively. Until some nice guy contributed a lot of code using GNU extensions, that is. Since it's *really* hard to modify this make process.

Often enough more is not better.

Otherwise CMake is "yet another tool" that requires additional maintainance.


So far I can't see how a package maintainers job becomes harder from using a custom build tool like "ant" and such. The maintainers care about the path of least resistance to get their configuration done. I see some preference for autoconf, mostly because that's what's known. Maintainers will often succeed by guessing "./configure&&make". But once one runs into this not working, it becomes manual tweaking source. This is either easy in any build system, because it's documented in the README where to assign which variables or it's hard work anyway, regardless of the build system.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]