R-alpha: Re: Separation of Program & Doc; REQUIRING Perl5 [was: New Version]
Martin Maechler <firstname.lastname@example.org>
Tue, 4 Nov 1997 11:52:42 +0100
[[Again I diverge to R-devel, I think we need more opinions here...]]
>>>>> "KH" == Kurt Hornik <email@example.com> writes:
>>>>> Ross Ihaka writes:
>> I am beginning to get a bit more free time and I would like to get a
>> "stable" version out as soon as possible. (This is of course so I can
>> break absolutely everything without feeling too much pressure to get
>> things working again quickly :-).
>> Using perl has produced some build problems because version 5 is not
>> a universal standard. There is even no guarantee that any kind of
>> perl would be available.
>> It would be nice if the installation could happen without perl. I
>> think this is possible if we separate the building of help files from
>> the compilation/installation of binaries. Preconfigured help files
>> could then be distributed separately for anyone who lacks (the correct
>> version of) perl, or at the cost of a little bloat, be part of the
I agree [see below]
>> Alternatively we could just say "YOU MUST HAVE PERL VERSION 5" and
>> enforce this with configuration checks. This is rather user-hostile,
>> but it does make things simple for us.
>> Watcha think?
KH> Well, better late than never (I was on a business trip for the past few
KH> days), let me say that I am very unhappy about splitting INSTALL into a
KH> doc and a non-doc part. Let me explain why.
KH> From a pedagogical point of view, it creates the impression that one can
KH> actually `install' a package without the documentation. This is not
KH> true, because the documentation is an integral part of the package. We
KH> need to force packages writers/maintainers into providing accurate and
KH> comprehensive documentation, and we need users to use it ...
Yes, [of course] I very much agree. You may (not) know that I got involved
in R hacking first with the aim of improving documentation considerably
and pushing the idea that we need interesting / relevant examples as
a very important part of docu.
KH> From the R Core group's perspective, (I think) it does not solve the
KH> problem. The problem is that although we would all be very happy to
KH> have Perl, and in fact version 5, available on all systems (and NOTE
KH> that we chose Perl because unlike the shell it is also available on
KH> non-Unix platforms, dubious as these may be), this does not seem to be
KH> that case. We now have Perl show up in both the documentation setup
KH> process as well as in at least one user-level function, with perhaps
KH> more to come.
hmm, I think that I said before that I don't like this (R function calling
perl) so much.
It is nice that for non-Unix platforms, Perl is more available than a shell
(with sed, awk, ....).
However, Perl is not (yet ?) part of standard Unix [unfortunately].
Using perl from R functions URGES users to have perl available.
This would prohibit the use of R for MANY who don't have a good access to
their system administrators [[which is not so rare, even at Universities..]].
The ``idea'' I got (which seems to be close to Ross' one) was:
A. For a Unix user, if she has perl available, she only needs the
base tar file, does ./configure and
make (good idea to INCLUDE 'make help' by default !) --> and has all
B. Unix users without Perl, or Windows / Mac users:
Besides the base tar/zip file,
they need to get the precompiled online help --- as distributed by CRAN,
in addition, and then can use (but not enhance conveniently) the help.
We could well setup things such that these users are really REQUIRED to
get the precompiled help (following the above point that the doc is
integral part of the software).
KH> Ross, as far as I understand your intentions, you want both `make
KH> install' and `R INSTALL pkg lib' to work even if Perl 5 is not there.
KH> The current solution (having install and INSTALL only operate things
KH> which do not depend on the availability of Perl 5) is a fix, but of
KH> course users could still do `make install-docs' and `R INSTALL-DOC' on
KH> the `unfortunate' platforms. What would happen then? Well, I think
KH> they should get a clean (and maybe not error-type) message saying sorry,
KH> you asked for something which requires Perl 5, which does not seem to be
KH> available on your system. Now, the best possible way for this to be
KH> accomplished would be via the configure script, which could not only
KH> check for where Perl is, but also whether it is version 5 or not, and
KH> record this information where needed. (Maybe even in the R shell
KH> script.) E.g., if Perl 5 was found, we'd have
KH> in etc/INSTALL, and then code like
KH> if [ "$PERL5" != "y" ];
KH> echo "Sorry, you need ..."
KH> exit 1
KH> Functions based on Perl scripts could be treated in a unified manner via
KH> a function perl(). Calling
KH> perl(script, arg1, arg2, ...)
KH> would under Unix be the same as
KH> system(paste("perl", arg1, arg2, ..., collapse = TRUE))
KH> but be set up in a way that a graceful error message is returned if Perl
KH> was not available at compilation time. In fact, we could even give
KH> perl() a named version argument, or use perl() and perl5()?
KH> (As an aside, my above reasoning also reflects my attitude that `make
KH> install' should automatically install the documentation as well.)
Once more, I almost agree on that.
I think `make' should install the program and doc
(== current `make install docs')
If perl is not available, installers should get your message above,
PLUS the hint that
1) they must get the pre-compiled help from CRAN
and AFTER installing it,
2) `make' (or maybe, even `make install-program')
will install the software alone [[docs being in place, unpacked from
precompiled CRAN help]].
KH> Enough said. Opinions?
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: firstname.lastname@example.org