On 12/05/2023 08:47, Iñaki Ucar wrote:
El vie., 12 may. 2023 5:58, Simon Urbanek
escribió:
I think it would be quite useful to have some community repository of code
snippets dealing with such situations. R-exts gives advice and pieces of
code which are useful, but they are not complete solutions and situations
like Dirk's example are not that uncommon. (E.g., I recall some of the
spatial packages copy/pasting code from each other for quote some time -
which works, but is error prone if changes need to be made).
This seems like a nice project for https://github.com/r-devel :)
Iñaki
I've also flagged in the #core-documentation channel of the R
Contributors Slack (https://contributor.r-project.org/slack). It may (or
may not) be something that they would like to look at during the
upcoming R Project Sprint. I know Jeroen previously provided some
guidance for rust (https://github.com/r-rust/faq) after a similar call
from Simon last year. Centralising some of this community provided
guidance under https://github.com/r-devel seems like it could be useful,
especially when there is an offer of review from R-Core.
Tim
If one has to rely on a 3rd party library and one wants to fall back to
source compilation when it is not available, it is a quite complex task,
because one has to match the library's build system to R's and the package
build rules as well. There are many ways where this can go wrong - Dirk
mentioned some of them - and ideally not every package developer in that
situation should be going through the pain of learning all the details the
hard way.
Of course there are other packages as an example, but for someone not
familiar with the details it's hard to see which ones do it right, and
which ones don't - we don't always catch all the bad cases on CRAN.
I don't have a specific proposal, but if there was a GitHub repo or wiki
or something to try to distill the useful bits from existing packages, I'd
be happy to review it and give advice based on my experience from that
macOS binary maintenance if that's useful.
Cheers,
Simon
On May 12, 2023, at 8:36 AM, Dirk Eddelbuettel wrote:
Hi Reed,
On 11 May 2023 at 11:15, Reed A. Cartwright wrote:
| I'm curious why you chose to call cmake from make instead of from
configure.
| I've always seen cmake as part of the configure step of package
building.
Great question! Couple of small answers: i) This started as a 'proof of
concept' that aimed to be small so getting by without requiring
`configure`
seemed worth a try, ii) I had seen another src/Makevars invoking
compilation
of a static library in a similar (albeit non-cmake) way and iii) as we
now
know about section 1.2.6 (or soon 1.2.9) 'Using cmake' has it that way
too.
Otherwise I quite like having `configure` and I frequently use it -- made
from 'genuine' configire.in via `autoconf`, or as scripts in shell or
other
languages.
Cheers, Dirk
PS My repaired package is now on CRAN. I managed to bungle the static
library
build (by not telling `cmake` to use position independent code), bungled
macOS but not telling myself where `cmake` could live, and in fixing that
bungled Windows by forgetting to add `src/Makevars.win` fallback. Yay me.
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
