[Osi] About packaging OSI

[Christophe-Marie Duquesne]

Hi,

I've been trying to use OSI on mainstream distributions and I always
ended up installing it by myself. I'm dreaming about simply typing
'aptitude install osi' (or any equivalent with yum, emerge, pacman...)
and getting what I want. That would indeed make the install procedure
of my own programs much easier for the end user. However, things
always go wrong, and though I once got a working osi configuration on
my archlinux, it had only support for Clp. I was never able to get OSI
and glpk working together this way.

For example, I'd like to be able to type 'aptitude install glpk
osi-glpk' and have a version of osi working with glpk out of the box.
Then when I get rich and I can afford cplex, I would simply type
'aptitude install osi-cpx', follow an installation procedure for cplex
described in a wiki, and I'd be done. Unfortunately, to my knowledge,
no distribution offers this kind of OSI packaging.

So, I'm seriously considering packaging OSI by myself. However, it
does not seem that simple, because supported solvers are decided at
compile time. So I was wondering: what is the right way to proceed?

Somehow, to package OSI properly, one would have to compile several
versions  (OSI currently supports 12 solvers, so at least 12). I'm
excluding compiling every possible configuration (imagine someone
owning Clp, Glpk and Xpress, and someone owning Clp, Glpk, Xpress and
Cplex, that would be two versions). I've come to think to a solution,
but it is not very elegant: compiling one version of osi for each
solver (that would support only this solver), and choose which version
of osi should be used using environment variables. The user would
install these versions with his packet manager.

# install osi with support for Clp, Cpx, Xpr would look like:
aptitude install osi-common osi-cpx osi-xpr

After this, the end user configuration would end up looking like this:

/usr/lib/osi-clp/lib/libosi.so
        |-/osi-cpx/lib/libosi.so
        |-/osi-xpr/lib/libosi.so

Then before using a program using osi, he would type something like
'module load osi-cpx' (that's the way to do it in fedora) and his
environment would then be set such that libosi.so is pointing to one
in /usr/lib/osi-cpx/lib/libosi.so (the one that supports cplex)

The problem with this kind of configuration is that it would require
programmers to rewrite their code a little, since this kind of switch
would not be allowed anymore:

  string solverName = userInput();
  OsiSolverInterface * osiPtr;
  if (solverName == "Cbc") {
    osiPtr = new OsiCbcSolverInterface();
  } else if (solverName == "Cpx") {
    osiPtr = new OsiCpxSolverInterface();
  }

Instead, a library to handle the solver creation could be written and
added to the OSI distribution. It would have an interface like this
one:

// file OsiSolverInterfaceCreator.hpp
class OsiSolverInterfaceCreator
{
  // returns the solver set by the user environment
  OsiSolverInterface * getNewOsiSolverInterface();
};

The programmer would include this file and following the user
environment, getNewOsiSolverInterface() would return a solver or
another one. The library corresponding to the header would indeed
change according to the environment variable and return the right type
of OsiSolverInterface.

Alternatively, one could write a library that still allows programmers
to choose the solver dynamically, embedding dlopen() and dlclose() and
loading the right library at run time:
// file OsiSolverInterfaceCreator.hpp
class OsiSolverInterfaceCreator
{
  // returns the solver specified by the string, opening the right
library with dlopen/dlclose
  OsiSolverInterface * getNewOsiSolverInterface(string solverName);
};

I was not able to think about a solution that would force the
developpers to change their code, but maybe there is one. So I'm
asking this mailing list: Do you see a more elegant way to handle
this? If you don't, do you think my proposition is acceptable? Are you
interested in this attempt of packaging OSI?

Best regards,
--
Christophe-Marie Duquesne
06 84 14 26 82 - mobile
04 76 57 48 06 - g-scop
04 97 23 27 33 - amadeus