Sorry for late reply.
Sukender wrote:
Another question: I spotted you posted a "curl_cmakify" archive a
few days ago. What is the link between this archive and the one
you just sent?
The 'cmakify' archive contained the script that constructed the CMake
build system for cURL. Well, "constructed" sounds too optimistic: its
main purpose was to compile the list of header files to check for, and
the 'config.h.cmake' files (analogous to autoconf's 'config.h.in', but
with different syntax).
The later archive contained the build system generated by this script
for curl-7.19.4.
Piotr Dobrogost wrote:
As to consensus; I think the task is to create as good CMake build
scripts as we can.
Having this CMake build scripts doesn't prevent having the hand
written
nmake makefiles as well. This would allow to build curl without using
CMake for those who doesn't want to use it.
In the future we could add boost.build scripts so that people used to
this build system could build this way.
The main reason I use CMake is to avoid abundancy in build system. If
you have autoconf on *nix and handcrafted nmake makefiles for Windows,
you have two separate build systems and a new task of keeping them in
sync.
If you have autoconf, nmake Makefiles, CMakeLists, boost.build, and,
say, scons files, you have yet another bunch of tasks for keeping the
build trees in sync.
So, I personally would prefer to have one build system for all cases.
CMake is a good candidate: it has lots of features, it's free, it's
actively maintained, and it works on many platforms.
--
tetetest tetetest.
