Chad Seibert wrote:
Previously, I mentioned implementing an LP library for Boost. However, there didn't seem to be a consensus on how I should go about it. If we can't agree on a method of attack, then there is no hope for me to get a proposal through the selection committee. So now, I solicit the communities advice on writing a wrapper for lp_solve, an LGPL library that purported to be one of the most stable free LP solvers. Do we care that a dependency is LGPL? I've done my due diligence and there doesn't seem to be a comparable MIT/Boost licensed library.
You should be able to define a generic C++ interface to an LP solver by defining what traits an LP solver has then implement adaptors for those traits for lp_solve. That way the library doesn't depend on lp_solve directly and the user is able to use the same generic C++ interface with the LP solver of their choice, including commercial solvers. That is what I would to, abstract away the solver so that any solver can be dropped in without changing the usage of the solver in client code. That is good design whether a particular solver has license issues or not. Regards, Luke