[MibS] add a build script for coin-or/Mibs

[odow]

Probably still a WIP, but let's see what the damage is on some other platforms.

This targets

• MibS 1.1.3 coin-or/MibS@4b7ec93
• SYMPHONY coin-or/SYMPHONY@c0a7550
• CHiPPS-ALPS coin-or/CHiPPS-ALPS@5b1a0b5
• CHiPPS-BiCePS coin-or/CHiPPS-BiCePS@bb7c56e
• CHiPPS-BLIS SaTahernejad/CHiPPS-BLIS@b714e6a

It's probably easiest to keep them bundled together like this for now. We can split of SYMPHONY as a separate solver at some point if there is interest, or if we start building other COIN software with the same dependency.

Unbundling

• SYMPHONY [SYMPHONY] add initial builder #3160
• ALPS [ALPS] add initial builder #3161
• BiCePS [BiCePS] add initial builder #3164
• BLIS [CHiPPS_BLIS] add initial builder #3183

cc @matbesancon
cc @joaquimg
cc @tkralphs
cc @HesamShaelaie

[odow]

Failures

• MibS-x86_64-apple-darwin looks like error: assigning to 'AlpsSearchType' from incompatible type 'int' coin-or/CHiPPS-ALPS#26
• MibS-x86_64-w64-mingw32-cxx11 et al looks like our favorite DLL export problem
• MibS-armv7l-linux-musleabihf-cxx11 et al. is something about incomplete types

../../../Alps/src/AlpsSubTree.cpp: In member function ‘AlpsReturnStatus AlpsSubTree::exploreUnitWork(bool, int, double, AlpsExitStatus&, int&, int&, int&, int&, int&, bool&)’:
[02:10:16] ../../../Alps/src/AlpsSubTree.cpp:1348:33: error: variable ‘AlpsSubTree::exploreUnitWork(bool, int, double, AlpsExitStatus&, int&, int&, int&, int&, int&, bool&)::mallinfo memInfo’ has initializer but incomplete type
[02:10:16]                  struct mallinfo memInfo = mallinfo();
[02:10:16]                                  ^~~~~~~
[02:10:16] ../../../Alps/src/AlpsSubTree.cpp:1348:52: error: invalid use of incomplete type ‘struct AlpsSubTree::exploreUnitWork(bool, int, double, AlpsExitStatus&, int&, int&, int&, int&, int&, bool&)::mallinfo’
[02:10:16]                  struct mallinfo memInfo = mallinfo();
[02:10:16]                                                     ^

[odow]

Well well! That took a while but not as long as I expected.

[matbesancon]

did you write the patch yourself or was it provided / recommended in one of the components?

[odow]

I wrote the patch.

The memory change is just commented out because I guess it uses some glibc stuff that doesn't work with musl. I didn't investigate further. It's optional, and not enabled for Mac or Windows.

The type cast should be upstreamed (job for @HesamShaelaie?).

[giordano]

It's probably easiest to keep them bundled together like this for now. We can split of SYMPHONY as a separate solver at some point if there is interest, or if we start building other COIN software with the same dependency.

Honestly I'm not a big fan of bundling multiple packages together, I prefer more granularity to maximise reusability, especially, as you noted, if these libraries are going to be dependencies of something else

[matbesancon]

I can understand for SYMPHONY. For the others, I am not sure there will be demand for reuse in other JLLs, they seem fairly specific.

[odow]

Maybe @tkralphs can chime in here: are there any other projects that would benefit from SYMPHONY (or CHiPPS) as a separate library?

If not, the dependencies are all on specific commits (not tags), and we intend to change them sometime this summer, so releasing everything separately is going to make things a bit harder. I'd prefer to keep as-is.

[giordano]

Other question: since this is a new package, is there any hope we can make it require Julia v1.6? It'd make adding more platforms later much easier.

[odow]

Yes, we could make this Julia 1.6+

[tkralphs]

Maybe @tkralphs can chime in here: are there any other projects that would benefit from SYMPHONY (or CHiPPS) as a separate library?

If not, the dependencies are all on specific commits (not tags), and we intend to change them sometime this summer, so releasing everything separately is going to make things a bit harder. I'd prefer to keep as-is.

The short answer is that yes, these should definitely all be packaged separately.

• SYMPHONY is a stand-alone MILP solver that itself could be directly used in JuMP and provides some unique capabilities on its own (such as the ability to solve lexicographic and biobjective MILPs). It is also an (optional) dependency of DIP. All in all, I don't think it would make sense to package it with MibS. (SYMPHONY is currently optional for MibS as well, provided Cbc is available, but I would still like to see it packaged).
• CHiPPS-ALPS is also a dependency of DIP, which is another project I hope to see packaged at some point and that could be interfaced to JuMP. With the addition of a few plug-ins, CHiPPS-ALPS could also be the basis for a simple framework for developing distributed tree-search-based algorithms, so it's potentially useful on its own. (Dip is also an optional dependency of OS, which could be packaged someday).
• Both CHiPPS-BiCePS and CHiPPS-ALPS are dependencies of DisCO.
• CHiPPS-BLIS is also a stand-alone, distributed MILP solver in its own right.

Of course, the audience for these things is not likely to be big, but not having them packaged separately would end up making life difficult for at least a few people, including me, so I'm willing to put some effort into it.

In general, all the projects in the COIN-OR Optimization Suite should be packaged separately. But I guess that the process should not be difficult, as they all use exactly the same build infrastructure.

[odow]

Thanks for the explanation!

DisCO would be good to have. We're missing an open-source mixed-integer conic solver other than Pavito/Pajarito.

I'll get to this next week.

[odow]

SYMPHONY is currently optional for MibS as well

What is the incantation for this? Omitting it causes an error that it is a required package?

[tkralphs]

SYMPHONY is currently optional for MibS as well

What is the incantation for this? Omitting it causes an error that it is a required package?

Hmm, yes, the configure script considers it required, but I don't think this is correct. It's true that some MIP solver is required and I think requiring SYMPHONY was just the easiest way to ensure that at the time. I'll take a closer look tomorrow and see how easy it would be to make SYMPHONY optional.

[odow]

@tkralphs I'm nearly there with this.

#3183 is building the master of coin-or/CHiPPS_BLIS. I checked and @SaTahernejad changes were merged in, so it looks like we don't need the fork.

This is also building using the regular SYMPHONY release, no the warm-start branch. So it seems fine on that end.

It should mean that there is a stab at getting DisCO to work. It'd be nice to have a MISOCP solver from JuMP in addition to Pajarito/Pavito.

[odow]

All ticks are green! This PR is good to merge on my end.