On Jan 9, 2014, at 1:51 AM, Pau Garcia i Quiles <pgquiles@stripped> wrote:
> No, there is no such thing as "CMake extensions".
>> Autoconf can create a CMakefile from a
>> CMakefile.in, and MySQL++ can use the config.h emitted by the configure
> Why would you want to do that?
Because it already exists, and many of the tests and flags defined in configure.ac only
make sense on platforms that can use Autoconf. There's no point rewriting those in CMake
Autoconf also provides a very useful service: substitution of the version number into
files that need it. Currently, there are *eight* of these. Can CMake do that? If not,
moving entirely to CMake increases the difficulty of producing a release.
It may be that, in stages, we gradually do away with Autoconf. I don't see a compelling
reason that we must do a big-bang conversion.
> Either you replace the whole build system, or
> you don't.
You're going to have to do better than vaguely predict "disaster" if you want to sway me.
What form will this disaster take? What breaks, specifically?
> Also, debugging was much more difficult because you didn't have a VS
I don't think that will be a serious problem for MySQL++. The Visual Studio debugger lets
a program linked to MySQL++ trace into MySQL++, which is how end users will be debugging
MySQL++, if they ever need to.
MySQL++ does ship many executables of its own, but except for the unfinished ssqlsxlat,
they are all examples, which should be debugged already.