[R-pkg-devel] Rcpp: how best to include source from another Github repository

John Clarke john@c|@rke @end|ng |rom corner@tonenw@com
Thu Jan 23 14:21:18 CET 2025


Thank you Dirk and Thibault for your additional tips and ideas.

I took a look at the vignette for *rcppcorels* and noted that this is
exactly the model/pattern I used to create my package. And it appears that
the /src files are simply copied from the external *corels* C++ library
into the rcppcorel's /src folder. And committed twice: once in the external
C++ repo and again in the rcppcorels repo. That is what I do now, but I
wasn't satisfied with the double commits and also I'd really like users of
the R package to have a reference/version/tag to confirm that what they
have in the R package is the same as a particular release of the C++ repo.

But in the end, it appears that there is no easy (and robust) way to do
this other than copy the files (via script or manually) and re-commit
changes in both repos. I suppose I could add a reference to the tag from
the C++ library, but this step can easily get lost/forgotten and is a
definite DRY violation. Maybe an import/copy script could help with that.

Thanks again for your help and suggestions.

-John











On Wed, Jan 22, 2025 at 8:53 PM Thibault Vatter <thibault.vatter using gmail.com>
wrote:

> There is balance between DRY, safety, and customization needs. The
> symlinkish approach would be "dangerous" imo, because you can't guarantee
> the wrapper.cpp will stay compatible with changes in the underlying C++
> library.
>
> The submodule approach works well. Alternatives that I know of are:
>
>
>    - a script that pulls the latest sources in the standalone C++ library
>    and does things like adding a preprocessor macro, see e.g. rvinecopulib
>    - a "patches" folder with patch files in diff format (.patch or
>    .diff), see e.g. RcppEigen
>
> Either way, such scripts or patches folders have to be excluded from being
> put into the package via the .Rbuildignore.
>
> On Wed, Jan 22, 2025, 2:33 PM John Clarke <john.clarke using cornerstonenw.com>
> wrote:
>
>> Thanks Ivan, this is helpful. I'll do some more research. It would be nice
>> to have an Rcpp standard/recommended way to do this. I don't want to have
>> a
>> non-standard ./src or ./data folder structure for my Rcpp package, but
>> these are the two relevant folders in my original repository. Maybe with
>> some sort of synlinking I could achieve this 'custom' folder/file mapping.
>> -John
>>
>> On Tue, Jan 21, 2025 at 1:05 PM Ivan Krylov <ikrylov using disroot.org> wrote:
>>
>> > В Tue, 21 Jan 2025 11:57:46 +0100
>> > John Clarke <john.clarke using cornerstonenw.com> пишет:
>> >
>> > > Ideally, it would be nice to be able to pull the files from the
>> > > source repo using a tag/hash so that the only code change in the Rcpp
>> > > repo would be that reference rather than all the changes to the
>> > > shared source.
>> >
>> > I've been using Git submodules for this purpose:
>> >
>> > https://codeberg.org/aitap/Ropj/src/branch/master/src
>> >
>> > https://git-scm.com/book/en/v2/Git-Tools-Submodules
>> >
>> > Every time the upstream changes I have to update the commit pointer in
>> > my repository too, but other than that, it's been working fine. My
>> > .Rbuildignore filters out all the unnecessary files included in the
>> > upstream repository, leaving only the relevant source code in the
>> > resulting source package.
>> >
>> > The resulting repository must be cloned with --recurse-submodules (or,
>> > if forgotten, must be initialised with git submodule update --init);
>> > further updates to the tracked commit pointer must be applied with git
>> > submodule update. If the referenced repository becomes unavailable, it
>> > will be impossible to build the package.
>> >
>> > --
>> > Best regards,
>> > Ivan
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list