Re: [R-pkg-devel] Check time > 10min

[Dirk Eddelbuettel]

Greg,

On 3 June 2025 at 21:22, Greg Hunt wrote:
| Dirk,
| Even if he gets the test and example times to zero, his total time in that
| thirteen minute run is still above ten minutes.  In my view the incomplete 
time
| reporting (we don't know what makes up the thirteen minutes) is a bug in the
| build process.  

Are you aware of these (documented, if you know where to look) environment
variables?  (Copied from my ~/.R/check.Renviron, and 2 mins may be too tight.)

_R_CHECK_INSTALL_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2
_R_CHECK_TIMINGS_=2
_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2
_R_CHECK_TEST_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2

Also, I am lost between your dualing propositions 'test and example times
[are] zero' and 'still above ten minutes'. Can you re-explain? Generally zero
is in effect less than 10.  So I must be misunderstanding something.

Dirk

| 
| Greg 
| 
| On Tue, 3 Jun 2025 at 10:54, Dirk Eddelbuettel  wrote:
| 
| 
| On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
| | My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0)
| because total check time exceeds 10 min (it's 760 seconds or 13 min). I
| can't see how to fix this as none of the times listed in the log https://
| win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/
| Windows/00check.log seems exceptional:
| | * checking CRAN incoming feasibility ... [18s] OK
| | * checking R code for possible problems ... [116s] OK
| | * checking examples ... [87s] OK
| | * checking tests ... [59s] OK
| | * checking re-building of vignette outputs ... [42s] OK
| | * checking PDF version of manual ... [32s] OK
| | * checking HTML version of manual ... [42s] OK
| | and the total of these components is only 396 sec (6.6 min), so I must 
be
| missing something. I would appreciate any advice.  Not much was added in
| this release, and I don't like the idea of blindly hacking off bits.
| 
| To a first approximation every tests is a function of some variable we can
| describe as 'N' which you, as author of the package and the tests,
| understand
| best.
| 
| Surely you must know a way to define a new N1 <- N/2, or some other
| appropriate scaling. Then try running with N1 instead. And you can also
| make
| both tests and examples _conditional_ on some other control variable.
| 
| It's all just code. Bend it like Beckham.
| 
| Dirk
| 
| |
| |       [[alternative HTML version deleted]]
| |
| | __
| | R-package-devel@r-project.org mailing list
| | https://stat.ethz.ch/mailman/listinfo/r-package-devel
| 
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Check time > 10min

[Greg Hunt]

Dirk,
Even if he gets the test and example times to zero, his total time in that
thirteen minute run is still above ten minutes.  In my view the incomplete
time reporting (we don't know what makes up the thirteen minutes) is a bug
in the build process.

Greg

On Tue, 3 Jun 2025 at 10:54, Dirk Eddelbuettel  wrote:

>
> On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
> | My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0)
> because total check time exceeds 10 min (it's 760 seconds or 13 min). I
> can't see how to fix this as none of the times listed in the log
> https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log
> seems exceptional:
> | * checking CRAN incoming feasibility ... [18s] OK
> | * checking R code for possible problems ... [116s] OK
> | * checking examples ... [87s] OK
> | * checking tests ... [59s] OK
> | * checking re-building of vignette outputs ... [42s] OK
> | * checking PDF version of manual ... [32s] OK
> | * checking HTML version of manual ... [42s] OK
> | and the total of these components is only 396 sec (6.6 min), so I must
> be missing something. I would appreciate any advice.  Not much was added in
> this release, and I don't like the idea of blindly hacking off bits.
>
> To a first approximation every tests is a function of some variable we can
> describe as 'N' which you, as author of the package and the tests,
> understand
> best.
>
> Surely you must know a way to define a new N1 <- N/2, or some other
> appropriate scaling. Then try running with N1 instead. And you can also
> make
> both tests and examples _conditional_ on some other control variable.
>
> It's all just code. Bend it like Beckham.
>
> Dirk
>
> |
> |   [[alternative HTML version deleted]]
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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

Re: [R-pkg-devel] Check time > 10min

[Sebastian Meyer]

Am 03.06.25 um 13:22 schrieb Greg Hunt:

Dirk,
Even if he gets the test and example times to zero, his total time in that
thirteen minute run is still above ten minutes.  In my view the incomplete
time reporting (we don't know what makes up the thirteen minutes) is a bug
in the build process.


It is indeed unfortunate and perhaps a bug that the Windows check log 
shows no runtime for



* checking whether package 'secr' can be installed ... OK


(which on the Debian check machine was reported with 164s)

as well as for the following checks of package loading
(which takes relatively long for 'secr', even on Linux, ~5s each):


* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking whether startup messages can be suppressed ... OK


Setting environment variable _R_CHECK_TIMINGS_=0 should reveal timings 
for these checks. (Check option --as-cran only shows timings above 10s 
by default.) I don't currently have a Windows machine at hand to test.


Best,

Sebastian



Greg

On Tue, 3 Jun 2025 at 10:54, Dirk Eddelbuettel  wrote:



On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
| My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0)
because total check time exceeds 10 min (it's 760 seconds or 13 min). I
can't see how to fix this as none of the times listed in the log
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log
seems exceptional:
| * checking CRAN incoming feasibility ... [18s] OK
| * checking R code for possible problems ... [116s] OK
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
| * checking re-building of vignette outputs ... [42s] OK
| * checking PDF version of manual ... [32s] OK
| * checking HTML version of manual ... [42s] OK
| and the total of these components is only 396 sec (6.6 min), so I must
be missing something. I would appreciate any advice.  Not much was added in
this release, and I don't like the idea of blindly hacking off bits.

To a first approximation every tests is a function of some variable we can
describe as 'N' which you, as author of the package and the tests,
understand
best.

Surely you must know a way to define a new N1 <- N/2, or some other
appropriate scaling. Then try running with N1 instead. And you can also
make
both tests and examples _conditional_ on some other control variable.

It's all just code. Bend it like Beckham.

Dirk

|
|   [[alternative HTML version deleted]]
|
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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

Re: [R-pkg-devel] Check time > 10min

[Greg Hunt]

Dirk,
To clarify the reference to zero cost.

If Murray is being told that total time is thirteen minutes and that the
time needs to be less than ten, he might try to reduce the cost of tests
and examples, but they don't in total add up to the required three minutes.
Even if the combined cost of tests and examples is reduced to zero he is
still not below ten minutes.

Greg

On Tue, 3 Jun 2025 at 22:47, Dirk Eddelbuettel  wrote:

>
> Greg,
>
> On 3 June 2025 at 21:22, Greg Hunt wrote:
> | Dirk,
> | Even if he gets the test and example times to zero, his total time in
> that
> | thirteen minute run is still above ten minutes.  In my view the
> incomplete time
> | reporting (we don't know what makes up the thirteen minutes) is a bug in
> the
> | build process.
>
> Are you aware of these (documented, if you know where to look) environment
> variables?  (Copied from my ~/.R/check.Renviron, and 2 mins may be too
> tight.)
>
> _R_CHECK_INSTALL_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2
> _R_CHECK_TIMINGS_=2
> _R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2
> _R_CHECK_TEST_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2
>
> Also, I am lost between your dualing propositions 'test and example times
> [are] zero' and 'still above ten minutes'. Can you re-explain? Generally
> zero
> is in effect less than 10.  So I must be misunderstanding something.
>
> Dirk
>
> |
> | Greg
> |
> | On Tue, 3 Jun 2025 at 10:54, Dirk Eddelbuettel  wrote:
> |
> |
> | On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
> | | My revision of package 'secr' fails CRAN pre-test on Windows (R
> 4.5.0)
> | because total check time exceeds 10 min (it's 760 seconds or 13
> min). I
> | can't see how to fix this as none of the times listed in the log
> https://
> |
> win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/
> | Windows/00check.log seems exceptional:
> | | * checking CRAN incoming feasibility ... [18s] OK
> | | * checking R code for possible problems ... [116s] OK
> | | * checking examples ... [87s] OK
> | | * checking tests ... [59s] OK
> | | * checking re-building of vignette outputs ... [42s] OK
> | | * checking PDF version of manual ... [32s] OK
> | | * checking HTML version of manual ... [42s] OK
> | | and the total of these components is only 396 sec (6.6 min), so I
> must be
> | missing something. I would appreciate any advice.  Not much was
> added in
> | this release, and I don't like the idea of blindly hacking off bits.
> |
> | To a first approximation every tests is a function of some variable
> we can
> | describe as 'N' which you, as author of the package and the tests,
> | understand
> | best.
> |
> | Surely you must know a way to define a new N1 <- N/2, or some other
> | appropriate scaling. Then try running with N1 instead. And you can
> also
> | make
> | both tests and examples _conditional_ on some other control variable.
> |
> | It's all just code. Bend it like Beckham.
> |
> | Dirk
> |
> | |
> | |   [[alternative HTML version deleted]]
> | |
> | | __
> | | R-package-devel@r-project.org mailing list
> | | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> |
> | --
> | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> |
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[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] Check time > 10min

[Dirk Eddelbuettel]

On 3 June 2025 at 15:36, Sebastian Meyer wrote:
| Am 03.06.25 um 13:22 schrieb Greg Hunt:
| > Dirk,
| > Even if he gets the test and example times to zero, his total time in that
| > thirteen minute run is still above ten minutes.  In my view the incomplete
| > time reporting (we don't know what makes up the thirteen minutes) is a bug
| > in the build process.
| 
| It is indeed unfortunate and perhaps a bug that the Windows check log 
| shows no runtime for

Oh I see.  Well I always took mine 'on another OS' as 'largely proportional'
which allowed me to, say, reduce overall test time by 50%.

It also helps that the testing framework I default to (tinytest, which I can
strongly recommend) defaults to showing test times so I generally have an
idea about relative 'cost' between different tests.

R itself adds timings to the test log but that is (arguably) rather hidden.
 
| > * checking whether package 'secr' can be installed ... OK
| 
| (which on the Debian check machine was reported with 164s)
| 
| as well as for the following checks of package loading
| (which takes relatively long for 'secr', even on Linux, ~5s each):
| 
| > * checking whether the package can be loaded ... OK
| > * checking whether the package can be loaded with stated dependencies ... OK
| > * checking whether the package can be unloaded cleanly ... OK
| > * checking whether the namespace can be loaded with stated dependencies ... 
OK
| > * checking whether the namespace can be unloaded cleanly ... OK
| > * checking loading without being on the library search path ... OK
| > * checking whether startup messages can be suppressed ... OK
| 
| Setting environment variable _R_CHECK_TIMINGS_=0 should reveal timings 
| for these checks. (Check option --as-cran only shows timings above 10s 
| by default.) I don't currently have a Windows machine at hand to test.

In general I think a policy of 'be more verbose' and 'have more generally
useful options on by default' would help.  This thread seems to show there
may be a need.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Check time > 10min

[Dirk Eddelbuettel]

Greg,

On 3 June 2025 at 23:58, Greg Hunt wrote:
| To clarify the reference to zero cost.  
| 
| If Murray is being told that total time is thirteen minutes and that the time
| needs to be less than ten, he might try to reduce the cost of tests and
| examples, but they don't in total add up to the required three minutes. Even 
if
| the combined cost of tests and examples is reduced to zero he is still not
| below ten minutes.

It is my (possibly wrong) understanding that _total time_ is not limited, but
test and example time are. It is the latter two this thread is about, not the
total time. Total time is much higher for some packages (arrow, duckdb,
terra, my own RQuantLib, the various *stan* packages, ...).

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Check time > 10min

[Greg Hunt]

Dirk,
In the original email, there was this:

* checking examples ... [87s] OK
* checking tests ... [59s] OK

Am I interpreting it wrong or are these numbers the elapsed times for
checking examples and tests?

Greg

On Wed, 4 Jun 2025 at 00:17, Dirk Eddelbuettel  wrote:

>
> Greg,
>
> On 3 June 2025 at 23:58, Greg Hunt wrote:
> | To clarify the reference to zero cost.
> |
> | If Murray is being told that total time is thirteen minutes and that the
> time
> | needs to be less than ten, he might try to reduce the cost of tests and
> | examples, but they don't in total add up to the required three minutes.
> Even if
> | the combined cost of tests and examples is reduced to zero he is still
> not
> | below ten minutes.
>
> It is my (possibly wrong) understanding that _total time_ is not limited,
> but
> test and example time are. It is the latter two this thread is about, not
> the
> total time. Total time is much higher for some packages (arrow, duckdb,
> terra, my own RQuantLib, the various *stan* packages, ...).
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[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] Check time > 10min

[Dirk Eddelbuettel]

Greg,

On 4 June 2025 at 00:19, Greg Hunt wrote:
| In the original email, there was this:
| 
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
| 
| Am I interpreting it wrong or are these numbers the elapsed times for checking
| examples and tests?  

If you follow the URL from the original post [1] you will see that it links
to a (Windows) check result ending in 'Status: OK'. No issue here.

Murray's original post also said '[it[ fails CRAN pre-test on Windows (R
4.5.0) because total check time exceeds 10 min (it's 760 seconds or 13 min)'.

So we are talking about two different checks.  As Seb alluded to, it is
unfortunate that the (failing) pre-check test does not give timings (whereas
the one you refer to does, but it did not fail).  Hth, and feel free to hit
me up off list with follow-ups as we may have gone on long enough on list.

Cheers, Dirk

[1] 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Check time > 10min

[Murray Efford via R-package-devel]

Thanks to Dirk, Greg and Seb for grappling with this. The comments give me 
confidence to appeal to CRAN to wave this through as it stands - I think Uwe 
has obliged in the past, but I would rather not rely on that. More complete 
reporting of check times would be welcome.
Murray

From: Dirk Eddelbuettel 
Sent: Wednesday, 4 June 2025 02:33
To: Greg Hunt 
Cc: Dirk Eddelbuettel ; Murray Efford 
; R Package Development 

Subject: Re: [R-pkg-devel] Check time > 10min


Greg,

On 4 June 2025 at 00:19, Greg Hunt wrote:
| In the original email, there was this:
|
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
|
| Am I interpreting it wrong or are these numbers the elapsed times for checking
| examples and tests?

If you follow the URL from the original post [1] you will see that it links
to a (Windows) check result ending in 'Status: OK'. No issue here.

Murray's original post also said '[it[ fails CRAN pre-test on Windows (R
4.5.0) because total check time exceeds 10 min (it's 760 seconds or 13 min)'.

So we are talking about two different checks.  As Seb alluded to, it is
unfortunate that the (failing) pre-check test does not give timings (whereas
the one you refer to does, but it did not fail).  Hth, and feel free to hit
me up off list with follow-ups as we may have gone on long enough on list.

Cheers, Dirk

[1] 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

[[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] Check time > 10min

[Joshua Ulrich]

Hi Murray,

On Tue, Jun 3, 2025 at 5:09 PM Murray Efford via R-package-devel
 wrote:
>
> Thanks to Dirk, Greg and Seb for grappling with this. The comments give me 
> confidence to appeal to CRAN to wave this through as it stands - I think Uwe 
> has obliged in the past, but I would rather not rely on that. More complete 
> reporting of check times would be welcome.
> Murray
>
I ran `R CMD check secr` on my Ubuntu machine and just the install
took a couple minutes (on one core). That time isn't reported as a
line item in the win-builder check log, but was close to half my total
check time. You might not have noticed this if you use something like
ccache.

For what it's worth, I'm running a Ryzen 7 3700X w/64GB of RAM that
was otherwise mostly idle. Here's the command I ran, with a few of the
reported timings for reference.

#> time CCACHE_DISABLE=1 _R_CHECK_TIMINGS_=0 R CMD check secr_5.2.4.tar.gz
* checking whether package 'secr' can be installed ... [152s/152s] OK
...
* checking R code for possible problems ... [30s/30s] OK
...
* checking re-building of vignette outputs ... [13s/13s] OK
* checking PDF version of manual ... [9s/9s] OK
...
real5m23.509s
user4m57.181s
sys 0m23.679s

Obviously my machine isn't win-builder, but it does suggest
installation is a big part of the total check time.

Best,
Josh

> 
> From: Dirk Eddelbuettel 
> Sent: Wednesday, 4 June 2025 02:33
> To: Greg Hunt 
> Cc: Dirk Eddelbuettel ; Murray Efford 
> ; R Package Development 
> 
> Subject: Re: [R-pkg-devel] Check time > 10min
>
>
> Greg,
>
> On 4 June 2025 at 00:19, Greg Hunt wrote:
> | In the original email, there was this:
> |
> | * checking examples ... [87s] OK
> | * checking tests ... [59s] OK
> |
> | Am I interpreting it wrong or are these numbers the elapsed times for 
> checking
> | examples and tests?
>
> If you follow the URL from the original post [1] you will see that it links
> to a (Windows) check result ending in 'Status: OK'. No issue here.
>
> Murray's original post also said '[it[ fails CRAN pre-test on Windows (R
> 4.5.0) because total check time exceeds 10 min (it's 760 seconds or 13 min)'.
>
> So we are talking about two different checks.  As Seb alluded to, it is
> unfortunate that the (failing) pre-check test does not give timings (whereas
> the one you refer to does, but it did not fail).  Hth, and feel free to hit
> me up off list with follow-ups as we may have gone on long enough on list.
>
> Cheers, Dirk
>
> [1] 
> https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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

Re: [R-pkg-devel] How to handle CRAN warning regarding stdout/stderr coming from code in upstream C library

[Ralf Stubner]

On Sun, Jun 1, 2025 at 1:15 AM SN248  wrote:
> ❯ checking compiled code ...
> > WARNING File ‘sundialr/libs/sundialr.so’:
> > Found ‘abort’, possibly from ‘abort’ (C) Object:
> > ‘../inst/lib/libsundials_core.a’
> > Found ‘puts’, possibly from ‘printf’ (C), ‘puts’ (C) Object:
> > ‘../inst/lib/libsundials_core.a’

One interesting side aspect is that while one of the warnings comes
from the .so file that will be used by R, most of the other messages
come from the intermediate .a files. You absolutely have to fix the
former ones. However, it sometimes happens that code is present in the
library and therefore compiled into the .a file, but it is not used in
the code exposed to R and therefore does not end up in the .so file.
In that case it helps to delete the intermediate .a file once the .so
file has been built. In swephR I do this with the following
src/Makevars file:

PKG_LIBS=-L. -lswe
PKG_CPPFLAGS=-I./libswe/ -DSTRICT_R_HEADERS

all: $(SHLIB) purify

$(SHLIB): libswe.a

LIBSWE = libswe/swedate.o libswe/swehouse.o libswe/swejpl.o libswe/swemmoon.o \
 libswe/swemplan.o libswe/sweph.o \
 libswe/swephlib.o libswe/swecl.o libswe/swehel.o
libswe.a: $(LIBSWE)
$(AR) rcs libswe.a $(LIBSWE)

purify: $(SHLIB)
@rm -rf libswe.a || true


ralf

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

Re: [R-pkg-devel] [Extern] Re: Problem building package depending on third party c++ source library.

[Ivan Krylov via R-package-devel]

On Sat, 24 May 2025 17:07:06 +0200
Nils Lüschow  wrote:

> Regarding the "mismatched-new-delete" warning I am also relatively
> sure that this is actually a false positive. Taking a look into the
> stack-trace, the new and delete operators are actually overloaded
> with functions that internally use malloc and free, hence, there is
> no mismatch

You're right, I see now that the call to free() is inlined into the
operator delete. This might be the same GCC bug as reported at
, but I've been
wrong about finding the exact problem before.

Generally, R CMD check will produce a NOTE if it sees you disabling a
compiler warning, but the compiler is in the wrong here, and a NOTE is
better than a WARNING. Still, it's best to have a package pass R CMD
check without even NOTEs because those don't need to be re-checked by a
human upon updates. Perhaps you could ask on Libera.Chat's #gcc channel
about possible workarounds? Sorry for not giving a more definitive
answer.

I've tried compiling the package on a Debian testing container, which
is the OS that runs the incoming package checks, and encountered even
more problems. Now gecode doesn't build at all, manually with
'./configure && make' or as part of the R package:

In file included from gecode/set/rel.cpp:39:
In file included from ./gecode/set/int.hh:296:
./gecode/set/int/weights.hpp:127:14: error: no viable overloaded '='
  127 | elements = elements0; weights = weights0;
  |  ^ ~
./gecode/kernel/data/shared-array.hpp:53:9: note: candidate function (the 
implicit copy assignment operator) not viable: 'this' argument has type 'const 
SharedArray', but
 method is not marked const
   53 |   class SharedArray : public SharedHandle {
  | ^
In file included from gecode/set/rel.cpp:39:
In file included from ./gecode/set/int.hh:296:
./gecode/set/int/weights.hpp:127:35: error: no viable overloaded '='
  127 | elements = elements0; weights = weights0;
  |   ~~~ ^ 
./gecode/kernel/data/shared-array.hpp:53:9: note: candidate function (the 
implicit copy assignment operator) not viable: 'this' argument has type 'const 
SharedArray', but
 method is not marked const
   53 |   class SharedArray : public SharedHandle {
  | ^

Additionally, gecode's ./configure wants to add --std=c++11 to the
compiler command line. I don't know if linking C++20 and C++11 code
would cause ABI problems, but it might better to configure gecode with
--enable-cpp11=no (since Makevars already gives the compatible standard
flag to ./configure).

-- 
Best regards,
Ivan

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