Help needed?

[ivan-pi]

Hello Sebastian,

I have the feeling like you went through the trouble of doing a full interface rewrite?

I had attempted a Fortran interface a few years ago, but never completed it: stevengj/nlopt#233
An issue I ran into at the time was memory leaks, when calling the remove inequality constraints.
Recently I also started to make an fpm compatible version in a private repo, after realizing this is in fact an easier distribution method than contributing to the upstream.

I understand you support both function and derived-type call back interfaces? 🚀 Just like I did you are using an adaptor pattern to conform to the original NLopt interface.

Are there any remaining areas where you could use some help? I'm very familiar with NLopt and even used it in a paper I submitted. I'm really happy I get to use it as a fpm package now!

[ivan-pi]

A few points I've noticed:

• you are missing the version, version_major, version_minor, version_bugfix routines
• handle_result could be expanded to report the reason it stopped (see https://github.com/stevengj/nlopt/blob/304137ff414be4c0f5abf72cda25bfb3ec2775d1/src/api/nlopt-in.hpp#L78 in the NLopt C++ wrapper) by adding a call to result_to_string

Also, I wonder if calling codes should really import the kind as wp => nlopt_wp? (Of course in big projects you still need to verify that the nlopt_wp parameter matches whatever precision is being used elsewhere.)

[awvwgk]

Sure, you're always welcome. I just invited you as a collaborator for this repository.

I've seen your fork, but considered it impractical to use a patched upstream version of nlopt due to the ABI compatibility issue this would introduce for different Fortran compilers. Instead I decided it would be preferable to use the excellent stability of the C-ABI and create a separate project that can be easily redistributed with the dependent projects.

My target is to have something that can be included in my tblite library (especially for the parameter optimization subcommand), which itself is a dependency of projects like DFTB+ (CMake based) or QCxMS (meson based).

[ivan-pi]

Instead I decided it would be preferable to use the excellent stability of the C-ABI and create a separate project that can be easily redistributed with the dependent projects.

I came to the same realization after we opened the pkgconfig issue in fpm, and realized it is easier to ship a nlopt wrapper as an independent project. They do the same for the Julia wrapper: https://github.com/JuliaOpt/NLopt.jl.