Revisit nagging about long-redundant Rcpp::LdPath() and alike

[eddelbuettel]

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

	* R/RcppLdpath.R (RcppLdPath, RcppLdFlags, CxxFlags, RcppCxx0xFlags):
	After discussion with CRAN, do not mark as .Deprecated() as too many
	packages are involved. This will need to be phased in more slowly.

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:

• add a message() this release cycle
• one or more release cycles later turn into warning()
• one or more release cycles later turn .Deprecated() back on

Thoughts?

[Enchufa2]

+1

[eddelbuettel]

One issue may be, I just realized, that use cases often involved a call from src/Makevars via cat() 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=code

[Enchufa2]

We need to write to stderr instead of stdout to avoid polluting the flags, right?

[eddelbuettel]

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.  

[eddelbuettel]

This has been addressed by #1413.