Skip to content

Detect UCRT-built R from within R sessions (and in configure.win)

8 messages · Hiroaki Yutani, Tomas Kalibera

Original
Hiroaki Yutani
# 
Hi,

Are there any proper ways to know whether the session is running on
the R that is built with the UCRT toolchain or not? Checking if the
encoding is UTF-8 might do the trick, but I'm not sure if it's always
reliable.

Also, I'd like to know if there's any mechanism to detect the UCRT in
configure.win. I know there are Makevars.ucrt and Makefile.ucrt, but
one might want to do some feature test that is specific to the UCRT
toolchain.

Best,
Hiroaki Yutani
Tomas Kalibera
#
On 9/8/21 2:08 PM, Hiroaki Yutani wrote:
There in not such a mechanism, yet, but can be added, at least for 
diagnostics.

You are right that checking for UTF-8 encoding would not always be 
reliable. For example, the version of Windows may be too old to allow R 
use UTF-8 as native encoding (e.g. Windows server 2016), then R will use 
the native code page as it does today in the MSVCRT builds.
We could add support for configure.ucrt, which would take precedence 
over configure.win on the UCRT builds (like Makevars.ucrt takes 
precedence over Makevars.win). Would that work for you?

Best
Tomas
Hiroaki Yutani
# 
Thank you for the prompt reply.
For example, can R.version somehow contain the information?
Yes, configure.ucrt should work for me. There might be someone who prefers
to switch by some envvar rather than creating another file, but I don't
have a strong opinion here.

Best,
Hiroaki Yutani

2021?9?9?(?) 0:48 Tomas Kalibera <tomas.kalibera at gmail.com>:

  
  


  


      

    

    
5 days later

    

      
      

        


  

        

      Tomas Kalibera
    

    

      
      #
    

  


  

      
On 9/9/21 5:54 AM, Hiroaki Yutani wrote:

            

      
      
      
    

        
Yes, now added to the experimental builds. R.version$crt contains "ucrt" 
(and would contain "msvcrt" if R was built against MSVCRT).

            

      
      
      
    

        
The experimental builds now support configure.ucrt and cleanup.ucrt files.

Best
Tomas

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Hiroaki Yutani
    

    

      
      #
    

  


  

      
Thanks for both, I'll try these features.

2021?9?14?(?) 22:40 Tomas Kalibera <tomas.kalibera at gmail.com>:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
5 days later

    

      
      

        


  

        

      Hiroaki Yutani
    

    

      
      #
    

  


  

      
I tried to use configure.ucrt, and found it results in the following
NOTE on the released version of R, unfortunately.

    * checking top-level files ... NOTE
    Non-standard file/directory found at top level:
    'configure.ucrt'

Will this be accepted by CRAN if I submit a package that contains
configure.ucrt? Or, is it too early to use it in a CRAN package?

In either case, while I don't have a strong opinion here, I'm starting
to feel that it might be preferable to provide an environmental
variable rather than creating ".ucrt" versions of files. In my
understanding, the plan is to switch all the Windows R to UCRT at some
point in future. But, it's not clear to me how to unify these ".win"
files and ".ucrt" files smoothly.

Best,
Hiroaki Yutani

2021?9?14?(?) 23:44 Hiroaki Yutani <yutani.ini at gmail.com>:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
3 days later

    

      
      

        


  

        

      Tomas Kalibera
    

    

      
      #
    

  


  

      
On 9/20/21 11:03 AM, Hiroaki Yutani wrote:

            

      
      
      
    

        
Thanks, that's right, so I've ported this part to R-devel and R-patched, 
configure.ucrt and cleanup.ucrt will be treated as "standard". There is 
nothing we can do about already released versions, the NOTE will appear.

You can also use configure.win and branch on R.version$crt, e.g.

!is.null(R.version$crt) && R.version$crt == "ucrt"

or

identical(R.version$crt, "ucrt")

            

      
      
      
    

        
With R.version$crt, you can already get a make (or even environment) 
variable. Writing R Extensions has examples how to invoke R in make 
files to get "R CMD config" values, so here you would invoke "Rscript" 
instead with one of the conditions above.

Either is fine. With .ucrt files, you can avoid copy pasting of common 
code using "include" directives. With the variable, you can use make 
conditionals. As you found now, with the variable you have the advantage 
of not getting a NOTE with already released versions of R. The .ucrt 
files are easier to maintain in hot-patches, but that is not an 
advantage for package authors.

Once a package depends on a version of R that will already use UCRT, one 
either would refactor/remove the conditionals, or integrate the ".ucrt" 
files back into the ".win". So, in the long term, there should be no 
conditionals on R.version$crt nor ".ucrt" files.

Best
Tomas

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hiroaki Yutani
    

    

      
      #
    

  


  

          

      
      
      
    

        
I noticed R-devel no longer complains about this from a while ago, thanks.

            

      
      
      
    

        
This slipped my mind, thanks for pointing it out! Yes, this works
perfectly without configure.ucrt. I will stick with this at least for
a while until the next version of R gets released.

            

      
      
      
    

        
I see, I think now I get your point. So, even if all the package
authors would choose to use the Rscript way, the .ucrt files would be
still needed to make room for the (R? or CRAN?) maintainers to
hot-patch the packages that don't work on UCRT nicely. Thanks for all
the efforts to make the UCRT R a reality.

Best,
Hiroaki Yutani

2021?9?24?(?) 2:16 Tomas Kalibera <tomas.kalibera at gmail.com>: