Brandon J. Van Every wrote:
Alan W. Irwin wrote:
This example of how CMake has quite casually taken over one autotoolized
project reflects in my opinion the fact that we live in a chaotic world
where small positive actions often have large positive consequences.
So in
such a world careful planning, discussion, and paying attention to
nay-sayers (who automatically always claim you have not done your
planning
carefully enough) can actually be counterproductive time wasting.
Instead,
my advice is to take small positive actions ("show them the code") to
see
what might happen whenever you have the opportunity to do so, and
always try
to identify nay-sayers (those who seem to get a kick out of always being
negative) and ignore what they say.... :-)
I would have never undertaken the Chicken Scheme build without Felix's
buy-in as a prerequisite. It sounds like you had some authority to
make things happen in the PLplot project. Or at least, your findings
would likely be taken seriously by a core group of programmers who
knew your work. Not everyone is in that position.
Not everyone coughs up the initial labor either. It would be useful
to track the status of CMake-ifying projects, to see who thrives and
who dies out.
For the record, I crossed the finish line, then the proverbial medics
carried me away on a stretcher.
Some private discussion with Bill has made me realize I'm not providing
enough context for what exactly is hard. Many of the problems of GNU
Autoconf build migration are not CMake's fault. They will happen
anytime one moves from a Unix-centric build culture to a truly
cross-platform Unix / Cygwin / MinGW / MSVC build culture. Because
Autoconf doesn't handle MSVC, builds typically have a completely
different build system for MSVC. This often means the internals of the
application have diverged, as was in the case of Chicken. Different
pathnames, different shell assumptions, different quoting problems,
etc. Getting an app to be truly cross-platform is a lot of gruntwork.
This is why I'm askance about some of the suggestions, like name
canonization, being a big improvement to CMake's future. Yes they'll
help, any good incremental design will help, but strategically it's just
not the core problem one faces when unifying a build.
The reason some Unix guys won't budge, has nothing to do with whether
CMake is a better tool than Autoconf. It's because going truly
cross-platform to Unix / Cygwin / MinGW / MSVC has no value to them, and
represents tons of gruntwork.
I would like to know in the case of PLplot, how mature the Unix / Cygwin
/ MinGW / MSVC builds already were. Did they all essentially work
already? Were they all well supported and tested? Were the app
internals essentially similar for all platforms, handling pathname
conventions gracefully and so forth? If all these things are true, then
that's a great app to CMakeify. If I could cherry pick what apps to go
after and convert, that's the sort of app I'd go for, because CMake
would ride the coattails of a bunch of build work that's already been done.
Cheers,
Brandon Van Every
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
