On Wed, 2008-12-03 at 02:36 -0800, Conrad Meyer wrote: > On Wednesday 03 December 2008 02:21:10 am Ralf Corsepius wrote: > > On Wed, 2008-12-03 at 01:36 -0800, Conrad Meyer wrote: > > > On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote: > > > > 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. > > What "new OS" has come out in the past 5 years or so that CMake doesn't > already support? That's the same school of thought which had killed imake. It dominated the world for almost a decade, then came Linux and the databases became unmaintainable, the X-consortium et.al. divorced, ... > > > > * 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. > > Saves resources on koji, if nothing less. It doesn't do so. The only difference is cmake carrying a vendor's preferences inside of itself, instead of rpm (from where autotools based configurations receive it). Helps vendors and package suites which are living in their "own solarsystem" (such as KDE), but isn't helpful in most other cases. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
