[CMake] CMake Marketing

[Chris Volpe ARA/SED]

I'm sure you're correct. I don't recall how new the stuff I was reading
was when I read it. And I may very well have gotten the replacement
wrong (scons vs autoconf).

-Chris
 
> -----Original Message-----
> From: cmake-bounces+cvolpe=ara.com at cmake.org [mailto:cmake-
> bounces+cvolpe=ara.com at cmake.org] On Behalf Of Brandon J. Van Every
> Sent: Wednesday, December 14, 2005 8:13 PM
> To: cmake
> Subject: Re: [CMake] CMake Marketing
> 
> Chris Volpe ARA/SED wrote:
> 
> > Somewhat related: I read recently that the Delta3D folks are
switching
> > from CMake back to autoconf due to dissatisfaction/frustration with
> > CMake.
> >
> Where are you reading this?  Can you provide a link to the post?  When
I
> Google around for info on this, I only find posts on the subject that
> are 8+ months old.  It seems they replaced CMake with SCons, not
> Autoconf.  I downloaded the sources and they now have a SCons based
> build in them.  Apparently their thinking was driven by a need to
> support Linux.  Previously they were doing mostly Windows and not much
> Linux.  They thought about Autoconf, probably not realizing how
> unworkable it is if you care about VC++.  Someone suggested SCons,
which
> is much saner, so unsurprisingly they went with it.  It looks like
they
> were either using Python anyways, or intending to.
> 
> SCons is a near competitor of CMake.  When I was shopping for a better
> Chicken Scheme build, my short list came down to CMake and SCons.  In
> fact there's some other guy working on a Chicken SCons tool, but CMake
> was blessed for Chicken builds.  Here, CMake had the advantage because
> it (1) didn't introduce a new language dependency, (2) was purpose
built
> to replace Autoconf, which we already had.  So, mindset and
methodology
> were similar.  This pattern will recur with any language
implementation
> that relies on GCC for its bootstrap.  I suggest these are people to
hit
> up.  Language guys don't want another language to boot their language,
> unless it is C.
> 
> Studying the strengths and weaknesses of SCons is going to be
important
> though.  It sits in a similar ecological niche and is most likely to
eat
> CMake's lunch.
> 
> > Has anyone talked to them to find out more details?
> >
> >
> >
> That's a good idea, although the picture is probably like I outlined
> above.
> 
> The main downsides I've had with CMake while learning it over the past
2
> months have been:
> 
> - incomplete documentation.  This is a big problem.  It's only because
> I'm strongly conditioned to read archives, use Google, grep source
code,
> bug people on mailing lists, etc. that I persisted.  In other words
I'm
> an "Open Source Survivalist."  Normal people aren't, and won't go to
> such elaborate lengths to try something out.  The current state of
> electronic documentation is not acceptable for mass awareness, i.e.
> having to hunt and peck on the wiki to find variable names, and even
> then the listings aren't complete.
> 
> - bugs.  But, these get fixed, and meanwhile there are workarounds.
I'm
> not worried about bugs so much.
> 
> 
> Cheers,
> Brandon Van Every
> I won't spend more than 1 day configuring 1 thing.
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake