RMySQL release candidate 0-7.0
Prof Brian Ripley wrote:
1) It seems that linking against libmysql.dll works on some versions and not others, so I've left it linking against libmysql.lib (which is an optional install). 2) There were lots of problems if MYSQL_HOME had a space in the path. It was easier to overcome these by using environment variables directly in src/Makevars.win. 3) It is possible to make use of mechanisms introduced in R 2.7.0 to set a DLLpath when loading RMySQL.dll and to retrieve the MySQL location from the Windows registry. So it really isn't necessary to install libmysql.dll. I've written and tested code which does that. 4) Distributing libmysql.dll without the sources is not allowed unless there is an exception somewhere I have not managed to find, as libmysql.dll is distributed under GPL-2. Although MySQL has an exception to allow combination with other FLOSS licences, it is not clear to me that you meet those conditions so perhaps even if you do distribute the sources the package has to be under GPL-2 (and some would interpet that as a requirement even by dynamically linking to libmysql). I don't see any advantage in not licensing RMySQL as GPL-2, which would avoid all the controversy. I'll push you in that direction by stating that the changes I have suggested I would much prefer to be incorporated under GPL-2. 5) Uwe Ligges and I and Dirk Edelbuettel (as maintainer) have worked out a way to have RPostgreSQL built on the main Windows package builder. We could try to do the same here, but none of us are happy with distributing a binary build that has no tests at all (as RMySQL runs no actual examples). So can we please have a test suite? You will need to allow the DBMS account, password and database name to be set via environment variables, as for RPostgreSQL.
I am happy to hear there is some progress on RMySQL. I can easily install some MySQL instance on the main builder in order to allow checks for RMySQL. Please provide the name of environment variables for account, password and database name that I will set on my machine, e.g. MySQL_database, MySQL_account, MySQL_passwd If you have such a version prepared, please send me the sources *before* submitting it to CRAN so that we can apply some checks in advance. Best wishes, Uwe
6) I've put a version of the revised sources I used to test on Windows (and with updated documentation and unused files removed) at http://www.stats.ox.ac.uk/pub/R/RMySQL_0.7-1.tar.gz I tested MySQL 5.0.67 on Windows and 5.0.45 on Linux, and I think these days we should only support MySQL 5. BDR On Fri, 14 Nov 2008, Prof Brian Ripley wrote:
I am pretty sure that distributing libmysql.dll (without the sources) is a license violation on MySQL, and in fact the binary releases made available on CRANextras did not distribute it. The Windows material in the RMySQL sources is years old, and not what has been used recently. My version of MySQL came with .a and not .lib, but neither are needed as you can link against libmysql.dll directly. I'll take a closer look when I have a machine booted into Windows that has MySQL installed, probably over the weekend. On Thu, 13 Nov 2008, Jeffrey Horner wrote:
Hi, I'm the new maintainer for RMySQL and I have a new release candidate for everyone to test. Please download the source or the binary here: http://biostat.mc.vanderbilt.edu/twiki/pub/Main/JeffreyHorner/RMySQL_0.7-0.tar.gz http://biostat.mc.vanderbilt.edu/twiki/pub/Main/JeffreyHorner/RMySQL_0.7-0.zip Issues related to memory leaks in dbConnect() and friends have been addressed, and the long-standing \r issue for dbWriteTable() has been addressed. Please provide feedback on these if you can. Also, I'd like the windows/R developer community to provide some feedback on the points below regarding how I've changed the build process: 1.a For previous RMySQL releases, there had been some incantations with reimp (utility in mingw NOT distributed in the latest Rtools.exe [not that it needs to be either]) and dlltool to create an appropriate libmysql.a library to link against. For 0.6-1 and 0.7-0 I could not get this to work. Instead, I chose to place the path to libmysql.lib right into the PKG_LIBS variable. For instance, this is my Makevars.win after an R CMD INSTALL: PKG_CPPFLAGS = -Ic:/PROGRA~1/MYSQL/MYSQLS~1.1/include PKG_LIBS = c:/PROGRA~1/MYSQL/MYSQLS~1.1/lib/opt/libmysql.lib 1.b In addition, binary releases up to and including 0.6-1 installed libmysql.lib and libmysq.dll into the package lib directory, while only the dll is installed for 0.7-0; the lib simply was not needed. 2. Previous RMySQL releases had the installer edit both configure.win and Makevars.win with appropriate paths. I've changed this so that the install only needs to set the env var MYSQL_HOME to an appropriate value, and if one is not provided, a default is chosen. Should a default be chosen or should configure.win fail? TIA, Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner
_______________________________________________ R-sig-DB mailing list -- R Special Interest Group R-sig-DB at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-db
-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595