Meson build system

[lukas-weber]

Hello and thanks for writing this library! I was able to get more than a threefold speedup over my own naive implementation of the revised simplex method when using it for some small problems.

Now as you know, adding library dependencies like HiGHS that are usually not installed on systems can be a chore, especially in an academic context where you run in environments you do not have complete control of. That is why for my projects I like to use the meson build system. The biggest benefit of meson me is that it makes vendoring dependencies completely trivial. If a library is not installed system-wide, it can download and build and use a fallback, all completely behind the scenes. This means you do not have to include a copy of the dependency code in your repository.

Another advantage of meson is its solid design: Build definitions get much shorter and you do not get into the same technicalities or legacy practices that you run into with CMake. The availability is also excellent because it can be simply installed on virtually any system not having it via pip. That is why an increasing number of open source projects are switching to meson, including for example systemd.

Now why am I writing this? The one thing required for the fallback mechanism mentioned above is that the dependency also uses meson. For this reason, I wrote a simple meson port of part of the HiGHS CMake build definitions. I am currently trying to get it accepted into mesonbuild/wrapdb#309 so that HiGHS becomes easy to use for all projects using meson.

Concerning this, I have two questions.

1. The most difficult part for the port is your usage of generate_export_header, which generates libhighs_export.h. In principle this header file does not depend much on the things CMake knows and the definition of different versions of the export macros for different compilers could also be done entirely in the preprocessor using a non-generated libhighs_export.h, arguably giving you more control over it, too. That is why meson does not have a similar function. My workaround is to supply a non-generated libhighs_export.h in my build system port, but including new source code files in such ports is against the rules of the meson wrapdb so that this is currently blocking the adoption of HiGHS: add wrap mesonbuild/wrapdb#309. Would you be okay with switching from generate_export_header to a non-generated export header?
2. In your CMakeLists.txt, I saw comments showing that you are not very happy with the old-style CMake practices. Instead of modernizing those definitions, would you be interested in giving meson a try as an alternative build system? Since I already wrote a functional meson port, this would be an easy thing to do. In particular, using meson fallbacks, you could easily decouple basiclu and ipx into their own dedicated libraries and repositories without making HiGHS development and usage more complicated.

[jajhall]

Thanks. Although I can't see us changing from CMake at the moment, I'll flag up your issue with the people in the HiGHS team who would appreciate the issue that you're raising.

[odow]

From my side, the Yggdrasil Julia build system supports meson, but I also don't see a need to switch at this point.

@lukas-weber I'm not part of the HiGHS team, but, a draft PR that demonstrated what would need to change for libhighs_export.h could be interesting if it let you create an independent meson build and let the HiGHS folks continue to use CMake.

[eli-schwartz]

Another option to consider might be supporting both. In particular, SciPy is moving to Meson and currently vendors HiGHS, then maintains the necessary glue code in the SciPy build system to build HiGHS as part of SciPy.

Use of subproject wraps would make this simpler, so they would probably be happy to help maintain the build files in this repository. This then makes it a lot easier to include HiGHS as a subproject in another Meson project -- no need to go through the thirdparty WrapDB, no need to limit oneself to the Meson WrapDB's "stable releases only" policy. SciPy can simply include this repo -- or the https://github.com/scipy/HiGHS fork without needing to rebase too much -- as a git submodule and it all just works.

/cc @rgommers

[rgommers]

Sure, if there's interest then I'd be happy to help maintain Meson support in HiGHS (and perhaps @mckib2 as well).

Here is our current meson.build file: https://github.com/scipy/scipy/tree/main/scipy/optimize/_highs. And we indeed also have a separate libhighs_export.h committed outside of the HiGHS git submodule: https://github.com/scipy/scipy/blob/main/scipy/optimize/_highs/src/libhighs_export.h

[mckib2]

Yes, I am willing to pitch in here. I understand it's an additional burden on any team to maintain two separate build systems, but there are a few of us I'm sure that can be on top of the meson side of things

[jajhall]

Thanks for the offers of support on this