Frederic Laruelle wrote:
>
> I hereby manifest my interest for Borland C++ support :-)...
The real problem is lack of an engaged maintainer. We need someone who
will 1) do the work to make the library build and run; 2) get the code
to the point that _all_ the examples run correctly; and 3) stick around
to provide continuing support. The last item is critical. Just making
the patch and then going away means that some time down the road, when
we break Borland support with some new feature, we'll again be
considering removing Borland support.
If we put Borland support back in the library, we want assurance that it
will not become a support nightmare in the future. If you can help
ensure that, read on.
The first issue is that with MySQL++ v2.1, we are looking at using
Bakefile to generate project files and such. Therefore, we need a
Borland user to check out the v2.1 branch from the Subversion repository
and try to get Bakefile to generate a project file that you can use to
successfully build MySQL++. This is almost guaranteed not to work
correctly right now, because even Unixy platforms aren't performing the
way I want yet. There's a lot of work to be done here.
Second, you need to test SSQLS. The last I heard, Borland compilers had
a 4K limit on macros, so the larger SSQLS macros couldn't be used. If
we are going to support Borland, we at least need to create a subset of
the SSQLS feature that will work for all supported compilers. If it
happens that the most recent version of the Borland compiler will build
MySQL++ without changes, then we have to ask whether we should just stop
supporting the older versions. All of these things require an active
maintainer. Even if someone bought me a copy of the Borland compiler, I
lack the time and interest to be the maintainer. We need an interested
Borland user to fill this role.
