Skip to content

[R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

5 messages · Gábor Csárdi, Jan Gorecki, William Dunlap +1 more

Original
Jan Gorecki
# 
Hi,
What is the recommended way to test for those issues locally?
If it is tested during cran submission, then seems reasonable to be enabled
just by --as-cran switch. Is it?
Thanks
On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, <rwoldford at uwaterloo.ca> wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


    

    

      
      

        


  

        

      Gábor Csárdi
    

    

      
      #
    

  


  

      
You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
use R-devel.

Alternatively, and you don't need R-devel for this, you can run R CMD
--html INSTALL on your package, and then look for messages that
contain "treated as a topic", e.g.

    curl_fds                                html
Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
link ?multi_fdset? in package ?curl? does not exist and so has been
treated as a topic

Gabor

        
On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki <j.gorecki at wit.edu.pl> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Jan Gorecki
    

    

      
      #
    

  


  

      
Thank you Gabor

        
On Thu, Jul 2, 2020 at 10:20 AM G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
On Linux you can use 'ltrace' to get a list of all the environment
variables that R looks up.  E.g., do the following in 'script' so all the
output is stored in a file ('typescript') and later look around in it for
the getenv calls.

$ R-devel --debugger=ltrace --debugger-args="-f -e getenv"
...
[pid 25055] libR.so->getenv("R_HOME")
 = "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("R_TRANSLATIONS")
 = nil
[pid 25055] libR.so->getenv("R_PLATFORM")
 = nil
...

            

      
      
      
    

        
25055] libR.so->getenv("_R_NS_LOAD_")                                   =
nil
[pid 25055] libR.so->getenv("_R_CHECK_ELAPSED_TIMEOUT_")
  = nil
[pid 25055] libR.so->getenv("R_CHECK_ENVIRON")
  = nil
[pid 25055] libreadline.so.6->getenv("HOME")
  = "/homes/bill"
[pid 25055] libR.so->getenv("_R_CHECK_TIMINGS_")
  = nil
[pid 25055] libR.so->getenv("R_ENABLE_JIT")
 = nil
[pid 25055] libR.so->getenv("R_HOME")
 = "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("_R_CHECK_USE_INSTALL_LOG_")
  = nil
[pid 25055] libR.so->getenv("_R_CHECK_SUBDIRS_NOCASE_")
 = nil
[pid 25055] libR.so->getenv("_R_CHECK_ALL_NON_ISO_C_")
  = nil
... hundreds more lines ...

            

      
      
      
    

        
Bill Dunlap
TIBCO Software
wdunlap tibco.com

        
On Thu, Jul 2, 2020 at 7:24 AM Jan Gorecki <j.gorecki at wit.edu.pl> wrote:

        

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Sebastian Meyer
    

    

      
      #
    

  


  

      
Has the discussion about potential updates to Rd2HTML come to an end?
Should I be prepared to fix non-file package-anchored links in
(non-roxygen) packages I maintain, i.e., look up the help file structure
of the referenced packages?

I don't yet believe that R has really given up on supporting
developer-friendly, direct and simple links to

             _topic_       rather than            _file_

\link[rgeos]{gIntersection}     -> \link[rgeos]{topo-bin-gIntersection}

\link[colorspace]{heat_hcl}     -> \link[colorspace]{rainbow_hcl}

\link[RColorBrewer]{brewer.pal} -> \link[RColorBrewer]{ColorBrewer}

\link[gridExtra]{grid.arrange}  -> link[gridExtra]{arrangeGrob}

\link[ggplot2]{geom_line}       -> \link[ggplot2]{geom_path}

for pointing to other packages which are only in Suggests and thus not
necessarily installed at install-time of the referencing package.

Topic-based links to external functions are so much more intuitive. I do
not understand why there should be a penalty for clearly identifying the
target package as opposed to just writing \link{topic} and hoping that
the intended package will be found by the help system at run time.

	Sebastian


Am 02.07.20 um 11:20 schrieb G?bor Cs?rdi: