Python is used by a broader range of data-science type people who can probably read a simple makefile but would balk at the complexity we have. So since we have Python as a dev dependency already, we aren’t paying much of a cost in terms of dependencies (pydoit is a simple Python module) but we could potentially make our build process accessible to a much broader range of people who are interested in Stan development.
We do a bunch of stuff that’s not a standard build task. For example we have (in stan-dev/stan at least) models that are used to generate c++, compiled to executables and then run for unit testing. Ideally we want to do more of that, for example when doing statistical testing on releases. Rather than stretching make I would prefer to take a tool that’s meant for those sorts of generalized tasks.
Bazel seems like a good example here because one of the ways that it can promise all the benefits it promises is that you must manually specify dependencies. I know that it has modules for things like protobuf that auto-generate c++ but they are serious projects done at least in part by people internal to Google and I’m not sure we have the people-power to devote to writing modules with equivalent functionality for Stan files. Maybe we could, I’ve never gotten far enough in understanding Bazel to figure it out. I do understand Bazel could be used to speed up our builds and I’ve noticed that it’s taken an increasing amount of time to get our builds through Travis/etc… (or even done on dev desktops for that matter) so maybe it’s worth it. But it’s not a clear win over something more generic at the top level since pydoit can easily defer to make for a sub-project (Bazel probably could too but IDK).
This part I’m not sure about, especially when it comes to ROI. I would like to understand this stuff
better mostly because the scientific projects I do require builds of both data-processing and software for reproducibility.
I do think the splitting will be easier than making all the tests pass so we can see how hard the latter is.