So I’m working on creating an msi installer using NSIS for Cmdstan.
One of the things I’m trying to do is to make the process happen within the Powershell terminal.
One of the nice things about the Windows 10 Powershell is that curl and tar come with the powershell
so I’ve been using them to help grab cmdstan from the latest release page and untar it into a directory.
The next thing I need to do is use make to build out cmdstan and
the command I’m using is
if you look at the blame you’ll see that we used to distinguish between Windows_NT and other. it’s possible that the generalized version didn’t anticipate running in the powershell? @rok_cesnovar ?
There is no issue with powershell, I have actually almost never used the regular command prompt on windows. Cmdstanr tests use powershell without issue as well.
Another thing is you should be using mingw32-make on Windows, but that is not the culprit here.
This seems to be some make that does not support recursive calls. So its definitely not the Rtools supplied one.
EDIT: Oh, I see you are trying to not use RTools. It seems the make you installed does not support recursive function calls in makefile, which is a deal breaker for cmdstan at the moment.
We obviously accept PRs to replace findfiles with anything else, but it has to work for both command prompt and powershell and be available without additional dependencies.
Hey @mitzimorris and @rok_cesnovar, thanks again for the feedback I appreciate it. So I didn’t realize that there was a change in the makefile in regards to findfiles and gnufind. The version of make I was using was very old it looks like but it was usable in the PowerShell.
Here’s the link to what I was using. http://gnuwin32.sourceforge.net/packages/make.htm
So it looks like a really old version that still seems to allow you to use make in the PowerShell terminal.
I’ll take a look to see if there’s a way around this maybe by looking at how to copy the mingw32-make exe file and run it in either the command prompt or PowerShell.
Something like that was done here.
I’ll try and also test with gnufind as well just in case it works.
This isnt really a recent change, I think at least pre 2.23 which is where I took a hammer to
all the various uses of GNU tools in our makefiles that caused issues on Windows.
Prior to that cmdstan required a bunch of GNU tools to run.
Thanks @rok_cesnovar, much appreciated! So the general direction I would like to go if possible is to not use MSYS2 or Rtools. My first idea was to figure out how to launch MSYS2 commands from NSIS scripts and I think I figured it out but ideally it would be better to have an executable generated that people can click and install without having to rely on those two things needed as a prerequisite. Though, if this route fails then the next idea would be to use MSYS2 like this through the NSIS script I’m doing through Execshell commands in NSIS.
I feel Stan is a bit too complex of a package and uses some complex libraries (sundials and TBB in particular) that will make it hard to work without tools like msys2, cygwin or something along those lines.
If we can make it work, that would be fantastic though.
agreed - it’s not that we don’t want to use MSYS2 - we need to use the minimal subset of MYS2 tools needed to make GNU-make and makefiles fly. this includes the correct C++ compiler and whatever unix utilities are used by the makefiles.
So I tried switching over to the chocolatey package manager for PowerShell. It acts like an apt-get for windows PowerShell and command prompt. One of the nice things about it is that it includes an updated gnu make command that is version 4.3. So the first thing I did was type the command
make clean-all
and the the result seems to work but for some reason there was a file pattern it couldn’t detect.
I think we should strive for an installer which provides a known, trusted C++ compiler, ditto known versions GNU-make, and whatever Unix utilities are needed by the Makefile rules - i.e., as much control over the toolchain as possible.
leaning on Powershell or Chocolatey puts us in the Mac OS bind, where updates to Xcode and the OS mess with our installer scripts.
that said, a working prototype would be nice just to let folks play around with the experience.
True I agree with you @mitzimorris , the reason I went on this detour is that I was curious about just testing this out as I couldn’t find any updated make command that was maintained after 2006 that could work in PowerShell. I’m going back to just trying to do this through MSYS2 at this point. Though, If I find a way to make this work in PowerShell later I’ll definitely release it to people.
Hmmm…something I might look into for the future is whether or not there are issues with file paths and whether or not there are expectations around “\” versus “/” for windows 10 in the PowerShell.