The Coin-OR stack is pretty complex with a huge dependency chain.
In general i would say, that the usual rules apply: easiest to hardest in general looks like
- System Packages
- Official Builds
- Build from Sources
In all cases it might be critical if someone only needs an executable (probably sufficient for pyomo) or a shared library (often easier to obtain the first; and always easier to provide some software to call the binary instead of linking or loading shared libs).
1. System Packages
This boils down to recognizing ones system and it's package-repositories. Then check is pre-made builds are available.
The usual cli-commands like lsb_release -a and the GUI-based package-managers can help.
For Coin-Cbc for example, one would find those.
2. Official Builds
It's sometimes not trivial to find those builds (and CoinOR is no exception in terms of competing documents where some are outdated and some are not). You will eventually see dead links (or 5 years old builds) trying to follow the links in Mark's answer: CoinBinary.
I would start with some of the development-places. While maybe not the core-dev place, Coin Cbc's github page for example links to this bintray providing builds.
3. Build from Sources
If there would be one thing i learned from the past it would be: CI can be a blessing! Exploit this.
Example
Let's give you some example with CHiPPS-BLIS. We want to develop something with it and therefore need our environment ready to link against it. It might be a good idea to build the current version from source and make use of it's makefiles for our work too (which is another terribly complex thing).
We start with above github entry and find Install.md:
We learn:
- There is an extra project available just for handling Coin-OR installs / dependency management / builds:
COIN-OR-OptimizationSuite
- This route is recommend in the
Install.md
But we will shortly recognize the outdated nature as:
./coin.install.sh fetch build --no-prompt --main-proj=Blis
will not do.
Now: outdated documentation is very common. But here there is a cure (and this covers most Coin-OR projects): Continuous Integration.
The main-page will show you some CI-buttons under section TESTING STATUS and it's green, so how hard can it be?
We might follow this one and arrive at some Travis-CI build.
Now we can emulate what's been done there and this case: we directly see the problem from before:
export PROJECT=`echo $TRAVIS_REPO_SLUG | cut -d "/" -f 2`
./coin.install.sh fetch --no-prompt --main-proj=$PROJECT > /dev/null
-> either one tries to understand the export syntax or one restrict to guessing
-> it's just the name within the travis-address:
-> https://travis-ci.org/coin-or/CHiPPS-BLIS/jobs/506947381)
CHiPPS-BLIS is the project name needed for COIN-OR-OptimizationSuite
Blis (as mentioned in Install.md) is not used (and won't work)!
Now there are other important things in those build-logs helping to make something work. We see for example which version is checked out (and guaranteed to build assuming we got the same sane system) and some dir-change order to follow.
In general, these CI-scripts, when maintained, really seems to help and i won't miss out on these in the future. The above was some Coin-focused example, but recently, i again failed following official install guides and made it work following CI with Google's or-tools (Coin deps, Protobuf deps and co.).
I think it's safe to assume, that outdated documentation is more common than failed and unhandled CI-checks which will result in some ugly broken flags (and usually E-Mails).
