Formulae to be added in order

[dpo]

(from https://projects.coin-or.org/CoinBinary/browser/OptimizationSuite/trunk/Dependencies)

• Data/Sample
• Data/Netlib
• Data/miplib3
• Data/Stochastic
• CoinUtils
• Osi
• Clp
• DyLP
• Vol
• Cgl
• SYMPHONY
• Cbc
• FlopCpp
• Smi
• CoinMP (to be moved from homebrew/science)
• Bcp
• Ipopt (bottled in homebrew/science—move?)
• Alps
• Bcps
• Blis
• Dip
• cppad (bottled in homebrew/science—move?)
• Bonmin
• Couenne
• OS
• examples

[dpo]

@tkralphs If we want to go ahead with #68, we have to revise most formulae. In particular, Homebrew now discourages a proliferation of options as we have here.

Specific questions:

1. If we're going to ship precompiled binaries, we should think of the most useful combinations of options. For example, is there any downside to shipping full-featured binaries (i.e., with all/most options activated)?
2. Another issue is dpo/openblas/mumps, which is used to build a sequential MUMPS library. Currently it's qualified as [:optional, "without-mpi"]. I suggest that I prepare a formula that only builds the sequential library and compile bottles for it. Would that work?
3. If we use OpenBLAS across the board, formulae become cross-platform and we don't need to make assumptions on what BLAS/LAPACK is available on the user's machine.

[tkralphs]

If we're going to ship precompiled binaries, we should think of the most useful combinations of options. For example, is there any downside to shipping full-featured binaries (i.e., with all/most options activated)?

I can't think of any real downside, the main thing is just that it means more dependencies, more build time, etc. It's not clear to me what impact it would have not to have these options activated. I don't think there would be a big impact for most users, but we can start with all options activated and see if there are complaints.

Another issue is dpo/openblas/mumps, which is used to build a sequential MUMPS library. Currently it's qualified as [:optional, "without-mpi"]. I suggest that I prepare a formula that only builds the sequential library and compile bottles for it. Would that work?

So you are suggesting to have a separate package for openblas that is sequential only in order to avoid having to use the without-mpi option when building?

If we use OpenBLAS across the board, formulae become cross-platform and we don't need to make assumptions on what BLAS/LAPACK is available on the user's machine.

Actually, one of the reasons I'm having trouble upgrading the packages on my old OS X box is because, among other things, OpenBLAS depends on gcc, which is a monster to build. I've tried to build it multiple times and the process has always ended in some strange error after a very long time. There are some other packages that seems completely unrelated to anything I've installed that stubbornly insist on being installed and also fail. So this proliferation of dependencies can be a bit painful. I guess on a newer machine and newer version of OS X, it's not an issue, but this is one argument for not throwing in everything and the kitchen sink as dependencies.

[dpo]

I can't think of any real downside, the main thing is just that it means more dependencies, more build time, etc. It's not clear to me what impact it would have not to have these options activated. I don't think there would be a big impact for most users, but we can start with all options activated and see if there are complaints.

If we ship binaries, it won't make much difference to the end user, except in terms of disk space.

So you are suggesting to have a separate package for openblas that is sequential only in order to avoid having to use the without-mpi option when building?

MUMPS, not OpenBLAS. Homebrew no longer accepts passing options to dependencies. We can keep :optional and :recommended dependencies though.

About OpenBLAS: we can leave it as :recommended so the binaries would be built against it, but in cases like yours, you would be able to build from source --without-openblas. You would have to build from source anyways if you have an old system because we can only precompile bottles for Catalina and Big Sur.

[tkralphs]

If we ship binaries, it won't make much difference to the end user, except in terms of disk space.

OK, yeah, that is true.

MUMPS, not OpenBLAS. Homebrew no longer accepts passing options to dependencies. We can keep :optional and :recommended dependencies though.

Ah, OK.

About OpenBLAS: we can leave it as :recommended so the binaries would be built against it, but in cases like yours, you would be able to build from source --without-openblas. You would have to build from source anyways if you have an old system because we can only precompile bottles for Catalina and Big Sur.

OK, sounds reasonable.