[R-pkg-devel] Flex missing in win-builder
Is it possible to get flex in the win-builder windows environment? It's present in the debian environment. My package depends on cmake, bison, and flex. Each of these are listed in the `SystemRequirments` field of my DESCRIPTION file but flex is the only one that cmake can't find. The win-builder home page (https://win-builder.r-project.org/) doesn't say much about foreign dependencies other than we have what's available in Rtools plus a small list of others. But neither cmake or bison are available by default in Rtools, they both have to be explicitly installed with `pacman`. Flex can also be installed via `pacman`, so why are the other two available? I can't find much on how the `SystemRequirments` is used in "Writing R Extensions" either, is this used to tell CRAN what is needed to build the package? Or is it just a hint to end users? If the former how are they supposed to be named? Different package managers have different names for the same packages. Does it need to be named `libfl-dev`? (This Rstudio repo: https://github.com/rstudio/r-system-requirements, makes it look like it's just a hint for humans.) If not able to access flex, I think I can generate the files locally and commit those but I'm pretty sure that will require doing what `rigraph` had to do and get `Make` compile all the external code that is currently handled by various `CMakeLists.txt` which is probably doable but looks like a lot work and requires manually regenerating and commiting flex files whenever updating external dependencies. Any better alternatives? [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Properly referencing copied code
I'm trying to submit a package to CRAN that uses external C libs but properly
crediting copyright holders and authors is the main issue holding up the
submission and I've repeatedly failed to satisfy the requirements. I am having
a lot of trouble understanding what/who I need to be listing in my DESCRIPTION
file and how they should be listed.
1. How does linking to external libs differ from providing the source of a
library and linking against that? Do I need to provide references to lapack and
blas if they aren't shipped with the package? What about math (lm)?
2. What roles to supply to authors of external software? After my last
submission, I got the note:
> Has copyright holders of included software in a [ctb] role only
>From the CRAN Repository Policy file:
>Where code is copied (or derived) from the work of others (including from R
>itself), care must be taken that any copyright/license statements are
>preserved and authorship is not misrepresented.
>Preferably, an ‘Authors@R’ field would be used with ‘ctb’ roles for the
>authors of such code. Alternatively, the ‘Author’ field should list these
>authors as contributors.
>
>Where copyrights are held by an entity other than the package authors, this
>should preferably be indicated via ‘cph’ roles in the ‘Authors@R’ field, or
>using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS file).
My interpretation of the CRAN policy is that the role 'cph' should be used only
for "entities other than the package authors" and therefore authors should only
get 'ctb'. Do I need to differentiate between authors with explicit copyrights
`c('ctb', 'cph')` vs those who are authors but are not listed as copyright
holders `c('ctb')` in the third party source? Or just give everyone both?
3. One of my dependencies has a lot of copyright holders throughout the source.
Most of these are for individual functions and cmake files that are not
directly used by my package. What is the best way to handle this? Add as much
of the unused parts of the third party package to the .Rbuildignore file as
possible to filter out the unused parts? (Many copyrights are from parts of the
package that are independent on the parts I used so for example ignore an
unused vendor package seems reasonable but what about hand picking the main
source files that are actually compiled to avoid copyrights?) Or list all of
the authors/copyrights in the my DESCRIPTION file?
4. Is there a better place to put all these authors? The author list has
already gotten large and I still have many more to add. I've seen use of an
`AUTHOR-list.md` in packages but I don't see this mentioned in official
documentation. In the previous quotation from CRAN's policy document, it
mentions the possible use of a `inst/COPYRIGHTS` file that is referenced in the
DESCRIPTION. Is there an equivalent for authors? Is it preferred to just put
everything in DESCRIPTION instead?
- DRC
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Properly referencing copied code
Thanks that helps. Are there any thoughts on the feedback I was given? I'm
still a bit confused on the note:
> Has copyright holders of included software in a [ctb] role only
I think I'm being asked to add the cph role to essentially every author in
addition to ctp but that doesn't seem to be what the CRAN policy wants and I
still don't know how to decide who gets both. Right now there are several
people who have explicit copyright over certain code so I would think just add
cph to all those authors? Or just give everyone cph who isn't a minor
contributor?
- DRC
On Friday, July 12th, 2024 at 3:07 AM, Ivan Krylov 'ikrylov at disroot.org'
wrote:
>
> В Thu, 11 Jul 2024 20:58:53 +
> DRC via R-package-devel r-package-devel@r-project.org пишет:
>
> > 1. How does linking to external libs differ from providing the source
> > of a library and linking against that?
>
>
> I think that the author information in the DESCRIPTION is about what
> your package provides by itself, not everything that may end up in the
> address space once the package is loaded. Since CRAN prefers
> self-contained packages, we end up including them in our packages
> (unless the third-party library is already very common and present in
> RTools & macOS recipes & common GNU/Linux distros), which requires us
> to specify their authors.
>
> > Do I need to provide references to lapack and blas if they aren't
> > shipped with the package? What about math (lm)?
>
>
> No.
>
> > 2. What roles to supply to authors of external software?
>
> > Do I need to differentiate between authors with explicit copyrights
> > `c('ctb', 'cph')` vs those who are authors but are not listed as
> > copyright holders `c('ctb')` in the third party source? Or just give
> > everyone both?
>
>
> I would expect most authors and contributors to be copyright holders
> too, but it must be possible to contribute without providing patches
> and becoming one. E.g. a project might recognise a tester and bug
> reporter as a full author, but there is no code that they own any
> copyright on.
>
> > 3. One of my dependencies has a lot of copyright holders throughout
> > the source. Most of these are for individual functions and cmake
> > files that are not directly used by my package. What is the best way
> > to handle this? Add as much of the unused parts of the third party
> > package to the .Rbuildignore file as possible to filter out the
> > unused parts?
>
>
> If it's feasible to implement, omitting unused files from the tarball
> is a good idea.
>
> > 4. Is there a better place to put all these authors? The author list
> > has already gotten large and I still have many more to add.
>
>
> CRAN recognises inst/AUTHORS. Here's a recently released package with
> no obvious problems that makes use of it:
> https://CRAN.R-project.org/package=xlcharts
>
> We should probably document it somewhere.
>
> --
> Best regards,
> Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Properly referencing copied code
Thank you everyone, I think this gives me everything I need to know and I have no problem spreading the copyright around. I'm not sure adding my dependencies to MXE is going to make sense here but open to being convinced otherwise. The package I am working on is wrapping functions from my own simple external C library. I wrote the C lib outside of the R package specifically so it would be possible to integrate the algorithm into multiple high level interfaces (i.e. python, matlab, in addition to R) otherwise the C would have been directly written into the R package. I don't see my lib as something anybody else is likely going to need to link against. This C lib does depend on igraph though, which is more likely to be useful. However, I don't think it's actually going to be straight forward to add to MXE given how much effort I have had to put into getting it to compile with R and I honestly would rather not be the one who needs to figure out how to do it right. I hope that is understandable given it's pretty clear I am out of my skill set as a biologist and that I am in the last few months of my PhD program and have already exceeded the time I can afford on this side project. There's a few problems that I think will make igraph difficult to package with MXE based on the challenges I have had with compiling on CRAN's build servers, assuming the environments are similar. 1. It was not possible for me to get igraph to compile correctly using cmake on CRAN builders due to other missing dependencies (including flex which I was previously told I have to pre-generate the resulting C files rather than depend on flex being available which prevents me from using cmake that calls flex itself). This means having to write new build logic instead of depending on the upstream cmake recipe, which is fragile and could break with an update. 2. There are some configuration options which are beneficial to choose based on the current project. Of particularly interest is that the igraph C lib has had to add a `USING_R` macro to modify the behavior in the lib based on whether it is used inside of `R` or not. Since MXE is not specific to R this requires a different build depending on where it's being used. 3. igraph is currently in the process of releasing 1.0.0 and the maintainers have noted there will be breaking changes. Given that it is not yet as mature as other commonly used dependencies, it is safer to use the pinned version shipped with my C lib than depending on a system wide installation. Even if there is a range of versions I can check for, I would think there would still be a need to ship an appropriate version of igraph with the R package (and therefore still have all the logic needed to build it) in cases where the system's available igraph version is not appropriate, igraph is not compiled in a thread safe manner, or igraph is not compiled for R (which it definitely wouldn't be anywhere not using MXE, i.e. on a Linux computer where `install.packages` will compile the package locally). As such I don't think it makes much sense to try to add it to MXE, especially before determining if there is demand for the lib in CRAN packages. - DRC On Monday, July 15th, 2024 at 4:11 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: > В Fri, 12 Jul 2024 20:17:22 + > DRC via R-package-devel r-package-devel@r-project.org пишет: > > > > Has copyright holders of included software in a [ctb] role only > > > > I think I'm being asked to add the cph role to essentially every > > author in addition to [ctb] > > > That's how I'm reading it too. > > > but that doesn't seem to be what the CRAN policy wants > > > I agree that there does seem to be a conflict, with the policy only > asking to use 'cph' for non-'aut' or 'ctb' copyright holders. > > > and I still don't know how to decide who gets both. > > > Technically, the conflict can be resolved by noting that the CRAN > policy doesn't prohibit using 'cph' for 'aut' or 'ctb' co-authors. > Since both your reviewer and help(person) ask for 'cph' for all > copyright holders, it sounds like all co-authors who wrote any code > should get an additional 'cph'. > > It would help if CRAN Policy also said that 'cph' should be used for > all copyright holders. > > > Right now there are several people who have explicit copyright over > > certain code so I would think just add cph to all those authors? Or > > just give everyone cph who isn't a minor contributor? > > > It shouldn't be too wrong to say that if someone wrote a nontrivial line > of code you're including in your package, they are a copyright holder. > >
