Repository navigation
Revisit nagging about long-redundant Rcpp::LdPath() and alike #1412
Description
Activity
+1
One issue may be, I just realized, that use cases often involved a call from
src/Makevarsviacat()which this may break. Hm.A quick spot check reveals no trouble.I guess that is what reverse dependency checks will be for.Edit: I used
::when I needed:::. There is plenty of it out there still: https://github.com/search?q=org%3Acran%20Rcpp%3A%3A%3ALdFlags&type=codeWe need to write to stderr instead of stdout to avoid polluting the flags, right?
Yes I was thinking about that too. Looks like we may be covered already:
‘message’ is used for generating ‘simple’ diagnostic messages which are neither warnings nor errors, but nevertheless represented as conditions. Unlike warnings and errors, a final newline is regarded as part of the message, and is optional. The default handler sends the message to the stderr() connection.This has been addressed by #1413.
- added a commit that references this issue
on Jul 29, 2026
A long time ago in a parallel universe far away we attempted to clean up use of (most of the) already-then ancient and unused helper functions in R/RcppLdpath.R. However, by jumping directly to
.Deprecated()we created too much line noise and rolled this back. ChangeLog has the goods:Rcpp/ChangeLog
Lines 2279 to 2281 in 274f5ab
That was seven (7) years ago. Ouch. Given the use of
#pragma message()for other coding styles we feel can be improved, I am planning to revisit this:message()this release cyclewarning().Deprecated()back onThoughts?