Hi Gregory,

See below.

On Jan 5, 2012, at 4:20 PM, gregory benison wrote:

>> As Duncan noted, the message is pretty clear in that the ODBC header files 
>> are missing, which are required to compile RODBC from source. On RH based 
>> Linuxen, this requires the installation of the unixODBC-devel RPM, much as 
>> one would need to have other *-devel RPMs (eg. readline-devel) installed for 
>> compiling many applications from source.
>> 
> 
> Since a lot of R users may not be familiar with these header files, I
> think the configure script could go a step further in explaining why
> it was looking for these headers (to find an installed ODBC driver
> manager), and that it didn't find one.  To illustrate what I mean,
> here is the result of running R CMD INSTALL on a system lacking an
> installed dsm where I swapped the order of the tests in configure.ac
> (see patch below) such that the library tests come before the header
> tests:
> 
>> * installing *source* package 'RODBC' ...
>> checking for library containing SQLTables... no
>> configure: error: "no ODBC driver manager found"
>> ERROR: configuration failed for package 'RODBC'
> 
> To me, that is a more helpful error message, because it makes it clear
> that you need to install an ODBC driver manager.

<snipped other content>

To split hairs, there are two issues at play here, irrespective of the ordering 
of the tests:

1. If you do not have unixODBC installed, you will get an error message 
regarding a missing ODBC driver manager, if as you have done here, that test is 
first rather than second.

2. If you have unixODBC installed (so you pass the first test in your 
scenario), but do not have the 'devel' part, which is a separate install on 
most Linuxen with package managers (RHEL/CentOS, Fedora, Debian and derivatives 
like Ubuntu and Mint, etc.), you will still get the error message regarding the 
missing header files. That is an entirely different error than missing the 
actual ODBC driver manager.

So you can argue about the ordering of the tests, but the end result is the 
same. Only if you have some knowledge about compiling source code (on ANY 
operating system), will you understand the meaning of missing header files AND 
only if you have some lower level knowledge of development on Linuxen 
specifically, will you know that the header files are contained in a separate 
binary package that needs to be installed as well, the details of which will be 
specific to the Linux distribution that you have chosen to install.

On top of that, if as with most Linuxen today, you don't have the software 
development packages installed (you are a naive user of Linux and only did a 
default install of the distribution), you won't have compilers and other 
associated tools (eg. make, etc.) installed either. At some point, the user has 
to be responsible for obtaining the requisite knowledge of their operating 
system, independent of the use of R. Despite the protestations by some on the 
web that their grandmothers are running Linux, it is still largely a geek's 
platform (with a 1% to 1.5% marketshare on the desktop) and due to the 
marketplace fragmentation of the plethora of distributions and desktop 
environments, further requires distribution and even version specific knowledge 
as well.

As I noted earlier, if you are going to use Linux, you are generally going to 
be expected to have a more technical level of knowledge than somebody who is 
running Windows or OSX, where for the most part, one can install pre-compiled 
binary packages from CRAN, thanks in large measure to folks like Kurt, Uwe, 
Duncan, Simon and Prof. Ripley (I may be missing others) who have taken the 
time over the years to put the testing and build infrastructure in place to 
automate much of that process.

Since there are over 3,500 packages on CRAN and some proportion (I don't know 
the number) have C/C++ and/or FORTRAN code in them, which will require 
compilation when installing source packages using either install.packages() or 
R CMD INSTALL on Linuxen, addressing RODBC in isolation is ultimately not 
helpful, since like most CRAN packages, it has a finite audience of users (me 
being very thankful to Prof. Ripley to be one of them).

I cannot speak for Prof. Ripley here, but since you seem to have the requisite 
skills, he may be open to accepting a patch against his package that would 
narrowly address the issue that you raise.

However, that does not change the defacto behavior for all of the other CRAN 
packages that will have similar requirements when being installed from source 
and will, as is the case with Linux generally, output relatively terse error 
messages when faced with these kinds of issues.

Also as Duncan noted, perhaps there may be a better mechanism in gaining access 
to install time requirements for CRAN packages. In the case of RODBC, Prof. 
Ripley has taken the time to create a vignette which covers much of this 
material. That is directly available from the CRAN page for the package, 
without having to successfully install or download the source package itself:

  http://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf

In other cases, such as with my WriteXLS package, I included an INSTALL file, 
which is also available separately from the CRAN page for the package:

  http://cran.r-project.org/web/packages/WriteXLS/INSTALL

In both cases, useRs need to know to look for that information, albeit not 
every CRAN package has such supplemental materials available. That is up to the 
package authors/maintainers.

The R Installation and Administration manual, which you initially referenced, 
can provide only very generic guidance for the installation of CRAN packages, 
since each of the over 3,500 packages may have very specific requirements 
beyond just the basic installation of a package that only contains R code and 
has no dependencies on third party tools. Some of the packages may even be OS 
specific (for example, BRugs, which is going to be problematic on Linux and OSX 
without a Windows VM or Wine, due to the requirements of OpenBUGS). This is why 
you are directed in the R Posting Guide to contact the package maintainer when 
faced with issues pertaining to a specific package alone or perhaps to one of 
the special interest lists, which in this case, for example, would be r-sig-db.

Regards,

Marc Schwartz

______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Reply via email to