date:20240117

Re: [R-pkg-devel] [EXTERNAL] Re: CMake on CRAN Systems

2024-01-17 Thread Sameh Abdulah

Thank you, Ivan and everyone else, for your help. We are working on modifying 
the package in line with your suggestions.

Regarding the Rcpp template we previously advertised, we are updating it to 
align better with the rules and constraints of R-exts. If you believe the 
template is still a potential example, we seek the community’s contribution to 
making it more tailored for the CRAN and R-exts rules, if not just ignore it.

Again, thanks for helping.


Best,
--Sameh

From: R-package-devel  on behalf of Reed 
A. Cartwright 
Date: Thursday, January 18, 2024 at 1:59 AM
To: R Package Development 
Subject: [EXTERNAL] Re: [R-pkg-devel] CMake on CRAN Systems
I think this is the same group that advertised an R package template a
while back that also clearly didn't follow R-exts rules or use any of
the best practices mentioned on this mailing list.

https://urldefense.com/v3/__https://github.com/stsds/Template-Rcpp__;!!Nmw4Hv0!2sMfEIGCOkf4K4xnMD01roSPe6BozSTq0MZKf1vY_MT-f6l4c-jX2I6SVogak9830IrKvZrbNEQkBIjkZfFeLm3SrrUW$


On Wed, Jan 17, 2024 at 3:24 PM Simon Urbanek
 wrote:
>
> I had a quick look and that package (assuming it's 
> https://urldefense.com/v3/__https://github.com/stsds/MPCR__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nsZNGlfE$
>  ) does not adhere to any rules from R-exts (hence the removal from CRAN I 
> presume) so the failure to detect cmake is the least problem. I would 
> strongly recommend reading the  R documentation as cmake is just the wrong 
> tool for the job in this case. R already has a fully working build system 
> which will compile the package using the correct flags and tools - you only 
> need to provide the C++ sources. You cannot generate the package shared 
> object with cmake by definition - you must let R build it. [In rare case 
> dependent static libraries are sometimes built with cmake inside the package 
> if there is no other option and cmake is used upstream, but those are rare 
> and you still have to use R to build the final shared object].
>
> Cheers,
> Simon
>
>
> > On Jan 17, 2024, at 8:54 PM, Ivan Krylov via R-package-devel 
> >  wrote:
> >
> > Dear Sameh,
> >
> > Regarding your question about the MPCR package and the use of CMake
> >  >  >:
> > on a Mac, you have to look for the cmake executable in more than one
> > place because it is not guaranteed to be on the $PATH. As described in
> > Writing R Extensions
> >  >  >, the
> > following is one way to work around the problem:
> >
> > if test -z "$CMAKE"; then CMAKE="`which cmake`"; fi
> > if test -z "$CMAKE"; then
> > CMAKE=/Applications/CMake.app/Contents/bin/cmake;
> > fi
> > if test -f "$CMAKE"; then echo "no ‘cmake’ command found"; exit 1; fi
> >
> > Please don't reply to existing threads when starting a new topic on
> > mailing lists. Your message had a mangled link that went to
> > urldefense.com instead of cran-archive.r-project.org, letting Amazon
> > (who host the website) know about every visit to the link:
> > https://urldefense.com/v3/__https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010328.html__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nnj6jJF1$
> >
> > --
> > Best regards,
> > Ivan
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nsmyJVkA$
> >
>
> __
> R-package-devel@r-project.org mailing list
>

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Reed A. Cartwright

I think this is the same group that advertised an R package template a
while back that also clearly didn't follow R-exts rules or use any of
the best practices mentioned on this mailing list.

https://github.com/stsds/Template-Rcpp


On Wed, Jan 17, 2024 at 3:24 PM Simon Urbanek
 wrote:
>
> I had a quick look and that package (assuming it's 
> https://urldefense.com/v3/__https://github.com/stsds/MPCR__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nsZNGlfE$
>  ) does not adhere to any rules from R-exts (hence the removal from CRAN I 
> presume) so the failure to detect cmake is the least problem. I would 
> strongly recommend reading the  R documentation as cmake is just the wrong 
> tool for the job in this case. R already has a fully working build system 
> which will compile the package using the correct flags and tools - you only 
> need to provide the C++ sources. You cannot generate the package shared 
> object with cmake by definition - you must let R build it. [In rare case 
> dependent static libraries are sometimes built with cmake inside the package 
> if there is no other option and cmake is used upstream, but those are rare 
> and you still have to use R to build the final shared object].
>
> Cheers,
> Simon
>
>
> > On Jan 17, 2024, at 8:54 PM, Ivan Krylov via R-package-devel 
> >  wrote:
> >
> > Dear Sameh,
> >
> > Regarding your question about the MPCR package and the use of CMake
> >  >  >:
> > on a Mac, you have to look for the cmake executable in more than one
> > place because it is not guaranteed to be on the $PATH. As described in
> > Writing R Extensions
> >  >  >, the
> > following is one way to work around the problem:
> >
> > if test -z "$CMAKE"; then CMAKE="`which cmake`"; fi
> > if test -z "$CMAKE"; then
> > CMAKE=/Applications/CMake.app/Contents/bin/cmake;
> > fi
> > if test -f "$CMAKE"; then echo "no ‘cmake’ command found"; exit 1; fi
> >
> > Please don't reply to existing threads when starting a new topic on
> > mailing lists. Your message had a mangled link that went to
> > urldefense.com instead of cran-archive.r-project.org, letting Amazon
> > (who host the website) know about every visit to the link:
> > https://urldefense.com/v3/__https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010328.html__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nnj6jJF1$
> >
> > --
> > Best regards,
> > Ivan
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nsmyJVkA$
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Yc-rZLeUomy6UfK2hWnlm7jSdZkb90h9QCvh1B8HkY97GxPB-zes4t2gnSD2fTupOOXR-HtLQODuWJl_l5l6nsmyJVkA$

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Simon Urbanek

I had a quick look and that package (assuming it's 
https://github.com/stsds/MPCR) does not adhere to any rules from R-exts (hence 
the removal from CRAN I presume) so the failure to detect cmake is the least 
problem. I would strongly recommend reading the  R documentation as cmake is 
just the wrong tool for the job in this case. R already has a fully working 
build system which will compile the package using the correct flags and tools - 
you only need to provide the C++ sources. You cannot generate the package 
shared object with cmake by definition - you must let R build it. [In rare case 
dependent static libraries are sometimes built with cmake inside the package if 
there is no other option and cmake is used upstream, but those are rare and you 
still have to use R to build the final shared object].

Cheers,
Simon

> On Jan 17, 2024, at 8:54 PM, Ivan Krylov via R-package-devel 
>  wrote:
> 
> Dear Sameh,
> 
> Regarding your question about the MPCR package and the use of CMake
> :
> on a Mac, you have to look for the cmake executable in more than one
> place because it is not guaranteed to be on the $PATH. As described in
> Writing R Extensions
> , the
> following is one way to work around the problem:
> 
> if test -z "$CMAKE"; then CMAKE="`which cmake`"; fi
> if test -z "$CMAKE"; then
> CMAKE=/Applications/CMake.app/Contents/bin/cmake;
> fi
> if test -f "$CMAKE"; then echo "no ‘cmake’ command found"; exit 1; fi
> 
> Please don't reply to existing threads when starting a new topic on
> mailing lists. Your message had a mangled link that went to
> urldefense.com instead of cran-archive.r-project.org, letting Amazon
> (who host the website) know about every visit to the link:
> https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010328.html
> 
> -- 
> Best regards,
> Ivan
> 
> __
> 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

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Matthias Gondan

Here's an example. It first checks if CMAKE_C_BYTE_ORDER is defined, which is 
available in recent versions of cmake. If it isn't, cmake's own macro 
TestBigEndian is invoked (deprecated, but still available). It would normally 
compile an executable, but we change the compile target to a static library 
(the test for endianness works anyway).

if(DEFINED CMAKE_C_BYTE_ORDER)
  if(CMAKE_C_BYTE_ORDER STREQUAL "BIG_ENDIAN")
set(WORDS_BIGENDIAN 1)
  else()
set(WORDS_BIGENDIAN 0)
  endif()
else()
  # From cmake docs: If CMAKE_OSX_ARCHITECTURES specifies multiple 
architectures, the value
  # of CMAKE__BYTE_ORDER is non-empty only if all architectures share the 
same byte
  # order.
  include(TestBigEndian)
  SET(CMAKE_TRY_COMPILE_TARGET_TYPE_SAVE ${CMAKE_TRY_COMPILE_TARGET_TYPE})
  SET(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
  TEST_BIG_ENDIAN(WORDS_BIGENDIAN)
  SET(CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE_SAVE})
endif()



> Gesendet: Mittwoch, 17. Januar 2024 um 16:52 Uhr
> Von: "Uwe Ligges" 
> An: "Matthias Gondan" , "Sameh Abdulah" 
> 
> Cc: "R Package Development" 
> Betreff: Re: [R-pkg-devel] CMake on CRAN Systems
>
>
>
> On 17.01.2024 08:59, Matthias Gondan wrote:
> > For package rswipl, cmake still seems to work, but
> >
> > * one has to search for it on MacOS, see the src/Makevars, as well as the 
> > relevant sections in Writing R extensions
> > * Windows Defender (also on CRAN) complains about dubious exe-files when 
> > checking the "endianness" of the target system. That can be circumvented by 
> > telling cmake to compile static libraries instead of executables.
>
> Indeed, currently Windows Defender gives false positives for some
> temprary .exe files that CMake creates. As thge filenames and locations
> are random, there is no straightforward way to tell the defender about
> exceptions. Hence please follow the advice and  tell cmake to compile
> static libraries instead of executables (an excellent idea, thanks!).
> [Microsoft knows about this for several weeks now without action.]
>
> Best,
> Uwe Ligges
>
>
>
> >
> > I am unsure if my response is specific to your problem, but the links below 
> > do not seem to work.
> >
> >> Gesendet: Mittwoch, den 17.01.2024 um 08:37 Uhr
> >> Von: "Sameh Abdulah" 
> >> An: "R Package Development" 
> >> Betreff: [R-pkg-devel] CMake on CRAN Systems
> >>
> >> Hi All,
> >>
> >> We recently encountered an installation issue with our package on CRAN. 
> >> We've been depending on CMake, assuming it is readily available by 
> >> default, but it appears to be only available on the M1mac system but not 
> >> on the others. Should we include the CMake installation within our package?
> >>
> >> We encountered another issue with OpenMP, but we managed to resolve it by 
> >> consulting the manual.
> >>
> >> https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$
> >>
> >>
> >>
> >> Best,
> >> --Sameh
> >>
> >> --
> >>
> >> This message and its contents, including attachments are intended solely
> >> for the original recipient. If you are not the intended recipient or have
> >> received this message in error, please notify me immediately and delete
> >> this message from your computer system. Any unauthorized use or
> >> distribution is prohibited. Please consider the environment before printing
> >> this email.
> >>
> >>[[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
>

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Uwe Ligges




On 17.01.2024 08:59, Matthias Gondan wrote:

For package rswipl, cmake still seems to work, but

* one has to search for it on MacOS, see the src/Makevars, as well as the 
relevant sections in Writing R extensions
* Windows Defender (also on CRAN) complains about dubious exe-files when checking the 
"endianness" of the target system. That can be circumvented by telling cmake to 
compile static libraries instead of executables.


Indeed, currently Windows Defender gives false positives for some 
temprary .exe files that CMake creates. As thge filenames and locations 
are random, there is no straightforward way to tell the defender about 
exceptions. Hence please follow the advice and  tell cmake to compile 
static libraries instead of executables (an excellent idea, thanks!). 
[Microsoft knows about this for several weeks now without action.]


Best,
Uwe Ligges





I am unsure if my response is specific to your problem, but the links below do 
not seem to work.


Gesendet: Mittwoch, den 17.01.2024 um 08:37 Uhr
Von: "Sameh Abdulah" 
An: "R Package Development" 
Betreff: [R-pkg-devel] CMake on CRAN Systems

Hi All,

We recently encountered an installation issue with our package on CRAN. We've 
been depending on CMake, assuming it is readily available by default, but it 
appears to be only available on the M1mac system but not on the others. Should 
we include the CMake installation within our package?

We encountered another issue with OpenMP, but we managed to resolve it by 
consulting the manual.

https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$



Best,
--Sameh

--

This message and its contents, including attachments are intended solely
for the original recipient. If you are not the intended recipient or have
received this message in error, please notify me immediately and delete
this message from your computer system. Any unauthorized use or
distribution is prohibited. Please consider the environment before printing
this email.

[[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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Tomas Kalibera




On 1/17/24 08:37, Sameh Abdulah wrote:

Hi All,

We recently encountered an installation issue with our package on CRAN. We've 
been depending on CMake, assuming it is readily available by default, but it 
appears to be only available on the M1mac system but not on the others. Should 
we include the CMake installation within our package?


Re Windows, see the documentation:

https://cran.r-project.org/bin/windows/base/howto-R-devel.html
https://cran.r-project.org/bin/windows/base/howto-R-4.3.html

cmake executable is available. But another issue is how well maintained 
are the cmake configuration files to find the software, etc.


You have most control when you specify the libraries for linking 
explicitly by yourself (and use just make/Makevars files), even though 
this can sometimes require manual changes for newer versions of Rtools 
(some libraries change linking often, most don't). This is the common 
way to do it (see the documentation).


You can also use pkg-config with the latest Rtools, and pkg-config is 
used internally by MXE, which provides some testing, and I've manually 
fixed a number of issues not detected by that testing. The advantage of 
pkg-config is that you don't have to specify the libraries yourself and 
it should reduce the need for updating your Makevars on Rtools updates. 
At the same time, it is much more likely to work than cmake, yet you 
could still easily run to issues, typically some dependency omitted.


I would not use cmake for an R package on Windows.

Tomas



We encountered another issue with OpenMP, but we managed to resolve it by 
consulting the manual.

https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$



Best,
--Sameh



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Additional Issues: Intel

2024-01-17 Thread Tomas Kalibera




On 1/17/24 09:41, Ivan Krylov via R-package-devel wrote:

В Wed, 17 Jan 2024 10:30:36 +1100
Hugh Parsonage  пишет:


I am unable to immediately see where in the test suite this error has
occurred.

Without testthat, you would have gotten a line by line printout of the code, 
letting you pinpoint the (top-level) place of the crash. With
testthat, you will need a more verbose reporter that would print tests
as they are executed to find out which test causes the crash.


The only hunch I have is that the package uses C code and includes
structs with arrays on the stack, which perhaps are excessive for the
Intel check machine, but am far from confident that's the issue.

According to GNU cflow, your only recursive C functions are
getListElement (from getListElement.c) and nthOffset (from Offset.c),
but the recursion seems bounded in both cases.

I've tried looking for variable-length arrays in your code using a
Coccinelle patch, but found none. If you had variable-bounded recursion
or variable-length stack arrays (VLA or alloca()), it would be prudent
to use R_CheckStack() or R_CheckStack2(size_of_VLA), but your C code
contains neither, so there's no obvious culprit. If you know about
R-level recursion happening in your code and have a way to reduce it,
that might help too.

Otherwise, it's time to install Intel Everything and reproduce and
debug the problem the hard way.


You could also try debugging using your toolchain, but with reduced 
stack size (e.g. ulimit -s). If you can make the error appear with a 
smaller but still reasonable stack size, chances are it is due to the 
same underlying problem.


Tomas





__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Additional Issues: Intel

2024-01-17 Thread Ivan Krylov via R-package-devel

В Wed, 17 Jan 2024 10:30:36 +1100
Hugh Parsonage  пишет:

> I am unable to immediately see where in the test suite this error has
> occurred.

Without testthat, you would have gotten a line by line printout of the code, 
letting you pinpoint the (top-level) place of the crash. With
testthat, you will need a more verbose reporter that would print tests
as they are executed to find out which test causes the crash.

> The only hunch I have is that the package uses C code and includes
> structs with arrays on the stack, which perhaps are excessive for the
> Intel check machine, but am far from confident that's the issue.

According to GNU cflow, your only recursive C functions are
getListElement (from getListElement.c) and nthOffset (from Offset.c),
but the recursion seems bounded in both cases.

I've tried looking for variable-length arrays in your code using a
Coccinelle patch, but found none. If you had variable-bounded recursion
or variable-length stack arrays (VLA or alloca()), it would be prudent
to use R_CheckStack() or R_CheckStack2(size_of_VLA), but your C code
contains neither, so there's no obvious culprit. If you know about
R-level recursion happening in your code and have a way to reduce it,
that might help too.

Otherwise, it's time to install Intel Everything and reproduce and
debug the problem the hard way.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CMake on CRAN Systems

2024-01-17 Thread Matthias Gondan

For package rswipl, cmake still seems to work, but

* one has to search for it on MacOS, see the src/Makevars, as well as the 
relevant sections in Writing R extensions
* Windows Defender (also on CRAN) complains about dubious exe-files when 
checking the "endianness" of the target system. That can be circumvented by 
telling cmake to compile static libraries instead of executables.

I am unsure if my response is specific to your problem, but the links below do 
not seem to work.

> Gesendet: Mittwoch, den 17.01.2024 um 08:37 Uhr
> Von: "Sameh Abdulah" 
> An: "R Package Development" 
> Betreff: [R-pkg-devel] CMake on CRAN Systems
>
> Hi All,
>
> We recently encountered an installation issue with our package on CRAN. We've 
> been depending on CMake, assuming it is readily available by default, but it 
> appears to be only available on the M1mac system but not on the others. 
> Should we include the CMake installation within our package?
>
> We encountered another issue with OpenMP, but we managed to resolve it by 
> consulting the manual.
>
> https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$
>
>
>
> Best,
> --Sameh
>
> --
>
> This message and its contents, including attachments are intended solely
> for the original recipient. If you are not the intended recipient or have
> received this message in error, please notify me immediately and delete
> this message from your computer system. Any unauthorized use or
> distribution is prohibited. Please consider the environment before printing
> this email.
>
>   [[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

Re: [R-pkg-devel] [EXTERNAL] Re: CMake on CRAN Systems

Re: [R-pkg-devel] CMake on CRAN Systems

Re: [R-pkg-devel] CMake on CRAN Systems

Re: [R-pkg-devel] CMake on CRAN Systems

Re: [R-pkg-devel] CMake on CRAN Systems

Re: [R-pkg-devel] CMake on CRAN Systems

Re: [R-pkg-devel] Additional Issues: Intel

Re: [R-pkg-devel] Additional Issues: Intel

Re: [R-pkg-devel] CMake on CRAN Systems

9 matches

Site Navigation

Mail list logo

Footer information