Operating System: Linux
Interface Version: CmdStan
Compiler/Toolkit: gcc/Ubuntu or RHEL
I notice “make install” has no effect in CmdStan. If you are willing to do it, or let me get somebody to do it, we’d be only a small step to having RPM and DEB packages of CmdStan. I did that packaging for OpenBUGS for several years, i can do for you too. The only part that we need, I think, is a “make install” functionality in your CmdStan makefile. Has this been discussed?
I just compiled this in Ubuntu 17.10 and it appeared smooth. If we packaged this up for easy installation, then a person could run your bugs_examples without a battle. As it is, I have students who have access to Rstan, but no CmdStan (because it is not packaged for Linux OS). It would be nice if I could put a package into the automatic update stream. I will do it if one of you will add the install magic to your makefile.
I’m not a Stan enthusiast, but I’m pretty good at Unix/Linux stuff and I could make this go forward.
Nothing came of it and things are a bit different now. I don’t think it would be that difficult to package it for an official repo, although they would require Stan Math to be its own library, use the system libraries for Boost, CVODES, and Eigen, separate out the tests and documentation into their own packages, etc.
This would be great. I’ve thought about trying to create a debian
package for Stan more than once.
One issue is the frequently-changing boost and eigen versions. My sense
was that to get into Debian (and, from there, Ubuntu) one needed to use
the versions of the libraries that ship with the OS.
Can you describe what’s usually included in make install? Right now, make build creates to binaries:
stanc: the Stan compiler. This is a transpiler that takes a Stan program and compiles it to C++.
stansummary: this summarizes Stan output.
A user of CmdStan will also need their own C++ compiler, access to Eigen and Boost (we include it in the CmdStan distribution, but we might be able to use an installed version), and the CVODES library (if using the ODE solver).
We’d also need to figure out how to build the C++ into an exectuable. That’s where I have trouble envisioning how that’s done. Any ideas?
We would need to get stanc installed like any other binary, but we’d also need to ship a script that packages the make recipe for building a Stan model. Currently we do something like:
make -C $CMDSTAN_DIR $MODEL
Where $MODEL is the absolute path to the model without the .stan extension. That’s pretty straightforward to script… even with just bash I think.
What I don’t know is what various distros would want done with the doc/tests and install locations.
I’ll have to study your workflow more. I did packaging for Swarm (Santa Fe Institute) way back when. This reminds me of that, a little bit.
What should happen after the build is that “make install” should copy the files to /usr/bin, /usr/lib, /usr/include, or where you want them to be. Debian and RedHat have standard places. There would be a template Makefile in /usr/share/stan/etc or possibly even /etc/stan. The examples you distribute would need their Makefiles adjusted to use that template. Let that standard makefile specify CXX and BOOST and soforth, the defaults according to the packaging.
Then users should be able to just type “make” in the project folder that has a Makefile. At least, Swarm did work that way, after a while. I was the packager, they had a GNU automake wizard who made the “make install” part come out as expected. In the worst case scenario, makefile needs a declaration like most of your makefiles in the examples folder have in line 1: STAN_HOME=…
With CmdStan I’ve run your bernoulli example, but nothing else. I will need more testing to see. I downloaded the stan-dev repository and am trying to run the bugs_examples collection. This is not completely obvious to me.
I can understand why you have not emphasized this in development. If the people who use R can get Rstan installed, it may be easier to give them an R script than a makefile anyway.
I also see now that this is sensitive to the particular editions of gcc or clang. That makes it especially exciting :)