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

Re: Status of libtool 2.2.X?



Matthew Woehlke wrote:
> Ralf Corsepius wrote:
>> On Wed, 2008-12-03 at 10:22 +0100, Kevin Kofler wrote:
>>> Ralf Corsepius wrote:
>>>
>>>> On Mon, 2008-12-01 at 22:28 -0500, Jens Petersen wrote:
>>>>
>>>>> I would add:
>>>>>
>>>>> * do not start new projects using autotools as far as possible
>>>> I would recommend you to stop spreading FUD.
>>> What FUD?
>>> There's an alternative which is:
>>> * easier to learn,
>>> * more portable,
>>> * more backwards-compatible (with its own previous versions),
>>> * faster,
>>> * generating nicer makefiles (progress percentages, color output),
>>> * designed in a better way (information is kept in central places
>>> instead of
>>> being copied into hundreds of projects),
>>> * used by more and more software, including big projects like KDE 4.
>>>
>>> It's called CMake.
>> See, all FUD, you simply are spraying hatred against something you don't
>> understand or don't want to understand.
>>
>> To me, cmake is
>> * not easier to learn, just different
>> * non-portable/inflexible.
>> * overladden with non-helpful gimmicks like progress percentages and
>> color output
>> * a crack ridden design (using a central database), reinvention of
>> imake, comprising it's design flaws.
> 
> I'm not going to contribute to the flamewar by commenting on any of the
> above (not in this thread anyway ;-) ), but...
> 
>> * a kde proprietary tool.
> 
> ...this last point (yes, even taking into account your "not useful
> outside of KDE" revision) is just plain wrong and reads like complete
> and utter ignorance of what CMake is. Yes, KDE4 uses it, but saying it
> is "kde proprietary" is just ludicrous.
> 
> Personally, I use CMake these days for pretty much every one-off project
> I do (and I'd promote it as the build tool of choice for any new
> project). Why? Because it's dead simple to write a trivial
> CMakeLists.txt that Just Works for basic stuff. For crying out loud,
> "hello, world" is one line! And the dependency graphs don't rely on
> gcc/m4/whatever. I use it for Qt-only apps. I use it for small C/C++
> projects and I'm working on a port of a large project incorporating C,
> C++ and Java (that needs to build on Windows also, plus a few even more
> esoteric and not-very-UNIX-like platforms).
> 
> CMake was not developed by KDE, nor for KDE. KDE is (one of) the most
> visibly FLOSS users of CMake, and *that's all*. It's /very/ useful as a
> general build tool.
> 
> Oh, and, autotools is of marginal usefulness outside of GNU. (Maybe
> that's not true /now/, but I'm quite confident it was when autotools was
> young.)
> 
> Ok, so I'll throw in my $0.02 anyway...
> 
> Autotools needs a POSIX shell... and for development, better have GNU
> gcc, make, sed, awk, m4, bison, probably others... for ANY project of
> non-trivial complexity (maybe even for trivial complexity, since I've
> never tried to develop an auto* project on a non-Linux platform).
> 
POSIX shell certainly.  gcc and GNU make definitely not.  Being able to
build when gcc and GNU make is not present is one of the reasons that
the autotools were created.

GNU m4 should only be required when the developer is modifying
configure.ac, not when the user is building. GNU sed, awk, and bison I'm
a little fuzzy in my memory but I don't believe the GNU versions are
required.  Better to ask an autotools guru about that, though.

-Toshio

Attachment: signature.asc
Description: OpenPGP digital signature


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