I’ve got another cmdstanr question – although I think this might apply more generally to CmdStan as well.
I’m on Windows 10 and recently installed R 4.0 and the new Rtools 4.0 and uninstalled Rtools 3.5 prior to that. When I wanted to update CmdStan via cmdstanr::install_cmdstan(overwrite = TRUE) it said that it could not find mingw32-make. I couldn’t find anything like that in Rtools 4.0, so I installed Rtools 3.5 again and just added its \mingw_64\bin\ to my PATH. Now everything works, but it’s a bit weird to have Rtools 4.0 and 3.5 installed simultaneously.
There is probably something I’m missing about using CmdStan/cmdstanr with Rtools 4.0?
Thank you so much! It’s not urgent as the above approach seems to work for now.
I just thought that in future more and more (Windows) people with R 4.0 (and Rtools 4.0) installed will try cmdstanr (hopfully!) and might run into this problem as well.
So does that mean that windows users have to follow these steps to get the needed make flavour?
Can you put this up on a wiki? Or could we even automate this for the users? It looks like it is easy in principle, but just another barrier which will stop a number of Windows users… sigh.
Would it be worthwhile to think about downloading binary TBB libraries (at least on windows)? I mean, we anyway already download the stanc3 binary.
Yes. Anyone using Rtools 4.0 will need to do that. Rstan will build the TBB lib its on way right?
I am slowly working towards a “How to install interface XYZ” page with clicking and all. I am slow with docs and writing (get easily distracted by coding :) ) but should be ready by the end of the week. I had to write some install instructions for a JMLR Stan GPU paper we submitted so I have some material to work with.
You can actually do
pacman -S mingw-w64-x86_64-intel-tbb
I am not completly sure what that does or where it places the TBB lib. It is promising and will look into it. But that will only come in handy for 2.24 as 2.23 will fail to build if not using mingw32-make.
This way of installing things will be how R 4.0 will operate on Windows. Users will do the same thing for any lib they need (openssl, xml2 and the likes). So I think this is actually an improvement.
Not really. We rely on the RcppParallel package which brings the TBB luckily in binary form (though in a rather oldish version which does not seem to matter as things are greatly compatible).
If we can get this working smoothly, then this is indeed an improvement. I would lean towards grabbing the binary TBB instead of building it. Then users would not even need anymore the mingw32-make. However, if we want to keep compatibility with RTools < 4.0, then we should probably stick with the mingw32-make … or is this pacman thing also available on RTools 3.5?
you are correct, technically its better to add the u as that also updates the packages on your system to a newer version if it exists. Will update my comment.