R-alpha: Re: Separation of Program & Doc; REQUIRING Perl5 [was: New Version]

Martin Maechler Martin Maechler <maechler@stat.math.ethz.ch>
Tue, 4 Nov 1997 11:52:42 +0100

[[Again I diverge to R-devel, I think we need more opinions here...]]

>>>>> "KH" == Kurt Hornik <hornik@ci.tuwien.ac.at> 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
    >> distribution.
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> PERL5=y

    KH> in etc/INSTALL, and then code like

    KH> if [ "$PERL5" != "y" ];
    KH> then
    KH> echo "Sorry, you need ..."
    KH> exit 1
    KH> else
    KH> fi

    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: r-devel-request@stat.math.ethz.ch