Wojciech Jarosz wrote:
I've been looking through other projects that use CMake in order to learn more. I've seen that some (Chicken, Scribus, for example) seem to have configure.in files in addition to CMakeList.txt files. I was wondering why one would use both autoconf and CMake in the same project?
Legacy support. I'd love to banish Autoconf entirely, but that's not politically doable yet. CMake still hasn't proven that it does everything right. For instance, right now I'm looking through the CMake archives about some kind of ld.so.conf issue on Linux. Apparently Autoconf does something automagically with library paths that CMake doesn't, and we need to do something additional on CMake. When you have an installed base that's using Autoconf, it takes a long time to migrate people to something new. People slowly poke at the new stuff eventually, and when it works better than the new stuff, people gradually switch. When it works the same, they don't tend to move on, they stick with what they know. And when the new stuff breaks, as inevitably happens with a new build system, they don't bother checking again for many months.
On the bright side, the other day CMake worked and Autoconf didn't, for some Linux build. That's progress. Means the breakage is occurring in the correct place. ;-)
Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
