[Rd] best way to build from Git

[Martin Maechler]

>>>>> Gábor Csárdi 
>>>>>     on Thu, 26 Dec 2019 08:23:10 +0000 writes:

    > Hi Frederick, I know some non R-core people use this
    > workflow to keep local patches in git branches:
    > https://bookdown.org/lionel/contributing/

    > Best, Gabor

Thank you, Gabor, and notably, Lionel, for providing the extras.

As Frederik notes / ask as well about it:
R-core people typically never build "inside the source tree"
(not "polluting" the source tree by built stuff)
but rather in separate build directory, as I'm pretty sure we've
recommended for years.

It would probably really be useful, if Lionel (or someone else)
updated his nice write-up and auxiliary {script / make} - files
so things work too when build with "src-dir != build-dir".

    > On Thu, Dec 26, 2019 at 1:37 AM <frederik using ofb.net> wrote:
    >> 
    >> Dear R-devel,
    >> 
    >> I checked out a recent copy of R via Subversion and made
    >> a few changes to the code. I wanted to commit them
    >> locally to my repo, just to stay organized and keep them
    >> separate from other changes I plan to make. However, I
    >> was not able to commit them because I don't think SVN
    >> allows this?
    >> 
    >> Plan B, check out a Git mirror of R,
    >> https://github.com/wch/r-source/
    >> 
    >> It has some instructions for building:
    >> https://github.com/wch/r-source/wiki
    >> 
    >> However, there are some complicated workarounds due to a
    >> commit from 2013
    >> (https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55fc6027af9ae9c7750a3).

    >> And it only seems to succeed if the build directory is the
    >> same as the source directory.

(I have not tried, as I as R-corer  do work with svn, but) If
this is true, then that is a pity indeed.
I have stopped of *ever* building in the source directory many
years ago, and I'm pretty sure that is the case for the vast
majority of R-corers.

    >> Makefile.in has some odd stuff that might be related,
    >> like why is it checking for "$(srcdir)/doc/FAQ" rather
    >> than "$(top_builddir)/doc/FAQ"? Conversely, there is a
    >> check for "$(top_builddir)/.git" which I would expect to
    >> be in "$(srcdir)/.git" instead. And it runs "git svn
    >> info" which seems to take indefinitely long - I am not
    >> using "git svn", I'm just trying to build from a regular
    >> git repo. This is difficult to debug because it is inside
    >> an @if, so "make -n" still runs it. Also there are no
    >> comments to explain what e.g. the "svnonly" target is
    >> doing, or anything else.

"svnonly" is mostly to distinguish an 'svn checkout' (which is
what all of R core work with) from the case of
(pre)released R, i.e., a source tarball which of course at this point in time is
unpacked into a source directory tree and to make sure that the
tarball does have a valid svn revision, via the SVN-REVISION
file (which now *is* in all tarballs as you can see).


    >> After some time I still have little idea why it is
    >> necessary for the build system to depend on the revision
    >> control system. Clearly we are trying to do something
    >> fancy, but why not e.g. just failover to "Last Changed
    >> Date: unknown; not SVN" if SVN-REVISION is missing?

almost surely because that will fail later: It is needed to
build the exact "R version":

> str(version)
List of 14
 $ platform      : chr "x86_64-pc-linux-gnu"
 $ arch          : chr "x86_64"
 $ os            : chr "linux-gnu"
 $ system        : chr "x86_64, linux-gnu"
 $ status        : chr ""
 $ major         : chr "3"
 $ minor         : chr "6.2"
 $ year          : chr "2019"
 $ month         : chr "12"
 $ day           : chr "12"
 $ svn rev       : chr "77560"
 $ language      : chr "R"
 $ version.string: chr "R version 3.6.2 (2019-12-12)"
 $ nickname      : chr "Dark and Stormy Night"
 - attr(*, "class")= chr "simple.list"
> 


    >> I am wondering if there is any plan to clean up this
    >> situation because it seems like a stumbling block for
    >> users who might want to contribute to R.

    >> Thanks,
    >> 
    >> Frederick