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

Re: Status of libtool 2.2.X?



On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote:
> On Wednesday 03 December 2008 01:31:20 am 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
> 
> Learning a new thing is always different. He's not telling you it's easier for 
> *you* to learn something new than something *you* already know, but that it's 
> easier for someone unfamiliar with autotools nor CMake to learn CMake than 
> autotools.

I would agree to "it's very simple to get into cmake for trivial cases".

For slightly non trivial cases, the autotools and cmake are more or less
on par wrt. difficulties. 

For complex cases, the flexibility the autotools provide pay off very
soon. On the downside, it's very easy to shoot yourselves into the foot
with them.

> > * non-portable/inflexible.
> 
> "FUD! FUD!"
Absolutely not: Try to bring cmake to a new OS and you'll experience the difference.

> > * a crack ridden design (using a central database), reinvention of
> > imake, comprising it's design flaws.
> 
> Reinvention of build-system-tools-in-general. Like a new version of autotools 
> (they don't pretend to be backwards compatible).
The autotools do not apply a central data base, they keep
"configuration" and "installation" as separate jobs. cmake lumps them
together.

It's a different approach.



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