Maciej Sobczak wrote:
> Mateusz Loskot wrote:
>
>>> What does prevent you from using CVS?
>> I believe my opinion well-known ;-) though it isn't important. The
>> only think that makes troubles is testing on Windows because CVS
>> authentication on SF.net requires me to load pageant + WinCVS +
>> manually select SSH key for pageant + setup key in SF.net
>
> This sounds like a local problem related to some desktop environment.
> This problem does not relate to C++ and even less to databases, so
> it has nothing to do with SOCI. Right? :-)
Hehe, you got me!
Yes, you're right :-)
> Is it fair to expect the SOCI project to solve somebody's local
> desktop configuration issues?
I'd not consider this issue in the terms of local configuration issues.
I'd consider them in terms of friendliness of project infrastructure.
Anyway, let's forget (for some time ;-))
>> I like current tests, except the lack of central configuration so I
>> could put all connection settings to soci_test.conf and then run
>> all-at-once using make check.
>
> What prevents you from providing the connection parameters as
> arguments to tests? If you need to store them in a config file, you
> can do it without involving the tests themselves. Right?
Requirement to hack it in N places instead of one.
Please, notice I'm talking about all at once testing using "make check"
I believe it's a good idea to be able to do:
./configure
make
make check
*without* hacking any of versioned files like Makefile.am or Makefile.basic.
>> Talking about CppUnit, *if* SOCI would need a unit test engine,
>
> SOCI does have a unit test engine already. It was prepared by Steve
> Hutton and it serves its purpose quite well.
Yes, and I'm happy with that except the lack of
out-of-the-box-all-at-once testing.
If something is scriptable or configurable, it should be scripted or
configured, to not to repeat ourselves (hack Makefile.{am|basic},
test, un-hack touched files, commit, hack-test-unhack-commit, ... - this
is the current process)
>> I second Maciek's proposal. Python bindings would be awesome!
>> However, I'd strongly encourage to use Boost Python instead of SWIG
>> or c-types. We (SOCI) already uses Boost, so we agreed on Boost as
>> a dependency.
>
> It does not really matter. The Python module would not be strictly
> part of the SOCI core library, but rather an add-on.
I believeit does, if we care about Python bindings.
If potential developer is not warned enough that he is about to wrap C++
API, which may change in future, and there is no guarantee on ABI
stability, then we will get requests to add a thing wrapper that
provides stable C API.
Boost Python solves this problem about wrapping heavily C++'ssed API.
However, if we don't care much, let's leave it to potential developer.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
