Add ipopt

[traversaro]

It would be great to have a port for the ipopt library ( https://projects.coin-or.org/Ipopt ) .
With respect to other ports, this may be particularly tricky as some of ipopt dependencies are Fortran libraries, see http://www.coin-or.org/Ipopt/documentation/node15.html .

[ras0219-msft]

The prebuilt binaries all link to the VS2010 runtime, so those are unfortunately not really suitable to use.

It looks like they recommend using the free fortran compiler f2c on windows at http://www.netlib.org/f2c. The portfile can download this during the build, so that should work.

On the other hand, it looks like their only build system is autoconf based, which is a much more serious blocker. We might be able to use WSL for this, though that would restrict it to Win10+.

More completely, we will most likely need to use MSYS2 to build this. I've opened #241 to track that.

[tkelman]

Ipopt depends on BLAS, LAPACK (#23), and at least one sparse linear solver to be functional. The only redistributable sparse solver that currently works is called MUMPS and it's in Fortran 90 so f2c does not work for it. Need to use either gfortran, or ifort, or one of the other sparse solver options (but those aren't freely downloadable unless you're an academic).

edit: you can get a personal license for MA27 which is Fortran 77 so f2c-able at http://www.hsl.rl.ac.uk/ipopt but not redistribute the result

[traversaro]

At the institution for which I work (https://www.iit.it/) we build binaries of IPOPT with MUMPS for MSVC 10/11/12 and soon 14, using the Intel Fortran compiler.

Currently we distribute them in an installer [1] with some other dependencies that we use, but I can try to get binaries of MUMPS suitable to be used in the vcpkg of ipopt.

[1] : http://wiki.icub.org/wiki/Downloads

[tkelman]

Is vcpkg intended to be for source builds only? Having non reproducible binary artifact dependencies would be a bit of an issue in that case, wouldn't it? Granted we're building on an OS and with a toolchain that aren't open source, but there's an assumption of easy availability for those components that everything else can be bootstrapped from, right?

[traversaro]

@tkelman at the moment, several ports just download and extract binaries already available, see for example tbb.

I think this make sense for ports without dependencies (because for a port with dependencies a change in the dependencies need to trigger a new build) and for project that is not possible to compile otherwise, as in this case.

[tkelman]

several ports just download and extract binaries already available

That largely defeats the purpose of having a build-from-source package management system. Homebrew and Nix do a very good job of distinguishing components that are built within the closed system from source in a controlled manner vs components that are used as binaries from elsewhere (casks in homebrew terminology, "impure environments" in nix). If vcpkg is going to require you to read the portfile for everything you install to know whether or not it's doing this, that greatly diminishes its usefulness.

If vcpkg is going to download binaries that were not built by vcpkg, then users have no way of verifying how they were built or reproducing them from a minimal bootstrapped environment (i.e. minimal toolchain install and nothing else) and sources. Isn't that one of the motivating design factors here, "developers need source code"? If that's not a principle that the public port files will follow, then I suspect people are more likely to use a package manager like conda that is designed to primarily download binaries and not require a toolchain for end-user package installation (and happens to have a much better selection of available packages, but that's mostly beside the point here).

[traversaro]

@tkelman I think you raise some interesting points for the vcpkg mantainers, but they are probably not directly related to goal of getting a working ipopt port given the current choices in vcpkgdesign. Probably a new issue is a more suitable place for discussing these aspects of vcpkg?

[tkelman]

Good point. There will be licensing implications of anything that links to or redistributes Intel's Fortran runtime library - it won't be GPL compatible, you couldn't link it into a combined GPL application and distribute the result. That's mostly a theoretical issue for now since Ipopt is not GPL, but would be worth annotating somewhere clearly if a binary repackaging of MUMPS were added here.

[traversaro]

Thanks a lot for this point, it is definitely interesting.

[ras0219-msft]

Is vcpkg intended to be for source builds only?

@tkelman While from-source is definitely preferred when available, having a binary-only package is still better than not having a package at all. For example, I'd happily accept (and prefer!) a rewrite of the tbb port that builds from source instead -- however I don't think we should hold the ecosystem hostage to force it.

We also completely recognize that there are many closed-source libraries out there that are successfully solving problems and we do believe in giving developers the option of using them if they believe the trade-offs are worth it.

If you'd like to continue discussing this point in another issue, I'd be happy to do so, especially around auditing! We certainly understand the need to audit your dependencies and if we can do better in this area (explicitly marking binary packages, perhaps?) then we should.

[traversaro]

I just found (thanks to #485 (comment)) an alternative CMake-based build system for IPOPT, in which MUMPS is built with gfortran and then linked to Visual Studio thanks to the GNUtoMS CMake property:
https://github.com/ampl/coin/blob/master/Ipopt/CMakeLists.txt

[traversaro]

Relevant: @albertziegenhagel pushed a port for MUMPS (a key dependency of IPOPT) in his own form of vcpkg, see #1098 (comment). This port requires the amazing Fortran support in vcpkg introduced in PR #1098 .

[chrisdembia]

Any progress on this?

[traversaro]

Not that I am aware of.

To be honest lately I have been wondering if it could make sense to add support for a simple linear solver to IPOPT to remove the dependency on MUMPS and hence on Fortran. I guess this could be slower, but could be convenient at least for prototyping. https://github.com/oxfordcontrol/qdldl could be a possible candidate, but I did not check in detail if it is actually suitable.

[tkelman]

That would not be suitable, you need a full Bunch-Kaufman indefinite factorization for Ipopt since it's designed to also (locally) solve non-convex problems. So nothing in SuiteSparse will help either. The only open-source solver I'm aware of that would be fully capable but isn't supported by Ipopt yet is https://github.com/ralna/spral, but that also depends on Fortran (it's by the same authors as the various HSL solvers, but newer).

[traversaro]

Thanks for the info and the links @tkelman !

[traversaro]

Related issue on Ipopt issue tracker: coin-or/Ipopt#370 .

[Janos95]

Maybe another way would be to use the pardiso solver which is part of intel mkl? I think there is already a port for mkl.

[NancyLi1013]

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

[traversaro]

The only open-source solver I'm aware of that would be fully capable but isn't supported by Ipopt yet is https://github.com/ralna/spral, but that also depends on Fortran (it's by the same authors as the various HSL solvers, but newer).

Related PR: https://github.com/coin-or/Ipopt/pull/414/files .

[eike-fokken]

I guess there are good news on this:

coin-or/Ipopt#446

Apparently spral support has been merged into ipopt and at least on version 3.14, my ipopt configure script knows the option --with-spral-cflags and its relatives.

[Cheney-W]

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

[zynfly]

It would be great to have a port for the ipopt library. I also encountered the problem of compiling ipopt on Windows.

[traversaro]

If I am not wrong this was finally fixed in #29398, thanks to everyone involved!