Open andrjohns opened 3 years ago
Additionally, while this approach copies the entire cmdstan
folder and all included libraries (e.g., Boost, Eigen), the next step after this is to allow linking to system libraries (e.g., libeigen3-dev
) on Linux so that only the Stan headers are needed
IMHO, this is hacking the Makefile one step too far.
both CmdStanPy and CmdStanR have scripts which install CmdStan, by default in a hidden directory ~/.cmdstan, cf https://mc-stan.org/cmdstanpy/installation.html#post-installation-setting-environment-variables
if you want to do this directly in the Linux shell, do this via a wrapper script, not the Makefile.
I tihnk this is a little different to the cmdstanR
and cmdstanPy
approaches. Those download and compile cmdstan so that cmdstanR and cmdstanPy can interact with them, while this approach is used to make cmdstan centrally accessible after compiling it.
It's pretty standard for a Makefile-based workflow to have:
make build
sudo make install
So I don't think I'd class this as 'hacking' the makefile
@wds15 You mentioned in another thread that your cluster has cmdstan
installed centrally, do you know their process?
Thanks Andrew!
I think this is valuable and there certainly are use cases of supporting this (there were requests for stuff like this on various repos). It looks to be relatively simple logic to add to makefiles (not trying to say that figuring it out wasnt hard work @andrjohns :), that certainly was) and would thus not be a burden for maintaining.
This will probably never become the default or recommended mode of working with cmdstan on a typical one-user setup, but that does not mean there is no need to support it.
OK, thanks for the clarification - no objections - go for it!
@andrjohns, would it make sense to "install" a script that builds so that it can handle spaces in paths? I can help spec and implement if that seems like something that would be good.
@andrjohns what are you asking for specifically? We use easybuild to manage dependencies and stuff. Together with the modules thing everything is managed nicely (e.g. the PATH variable is extended to include cmdstan bin dir). We also provide a cmdstan-make command which frees the user from having to change into the cmdstan dir to do compilation of a model.
It is probably a good idea to pass additional arguments to make
via the command you setup. You can accomplish this by adding "${@:2}"
to the end of the make call, this will pass all remaining arguments (starting with $2
). This would let you do something like cmdstan_model myfile.stan CXX=mpigcc
Summary:
A request that's come up before is the ability to centrally install cmdstan after building. I've put together an initial attempt at a makefile target, so that a user can run:
Which will copy the cmdstan directory to the
/opt
folder (/usr/local/opt
in OSX) and create a wrapper around the call tomake
to reference the correct directory:cmdstan_model
.The user can then just call
cmdstan_model path/to/model
to compile stan models.The makefile changes are on this branch
I still need to do some testing on the OSX side, but was hoping to get input on the current approach.
Is
cmdstan_model
a good name here? It's likely thatprint
anddiagnose
will need a similar prefix to avoid clashing with system binaries.Current Version:
v2.27.0