The package provides pkg-config files, which work everywhere, and cmake files, which work in a handful of places.

Building with cmake results in no pkg-config files installed, plus an extra makedepends on cmake. Building with autotools results in no cmake files installed. I suggest you discuss this with upstream, and possibly also discuss this with downstream projects that don't know how to link to arpack using the universal pkg-config standard.

...

Installing additional headers seems reasonable. Wonder why this isn't the default.

That's not true, their CMake scripts generate both, pkg-config and .cmake files, see here https://github.com/opencollab/arpack-ng/blob/master/CMakeLists.txt#L620 For ARPACK there's no disadvantage building with CMake. It is possible using pkg-config with CMake easily, but in general it's a bother for cross platform projects, since you don't have pkg-config on Windows outside of MinGW and therefore having the CMake configs is the preferred way for modern projects.

As for why ICB isn't default: iso_c_binding is Fortran 2003 and requires a compiler that supports it - the rest of the project is Fortran 90. For GFortran that's not a concern though. However, detecting whether a compiler supports it or not is difficult, and not easily doable in autotools or CMake.

So it builds the pkg-config file and doesn't install it... nice. That was not obvious. Why would they explicitly avoid installing it? Why would one want to avoid installing it in the first place, ever? Certainly we don't want to do any such avoidance...


- We are on Linux.

- Sane people don't develop on Windows but use MinGW (and Microsoft acknowledged this so hard they created WSL just so developers could use cross-platform tools that include pkg-config).

- macOS has pkg-config too.

- CMake configs *cannot* in any sane world be the "preferred" way for modern projects that just so happen to use build systems other than CMake (like plain make or ninja, autotools, meson, gn, scons, premake, integrated language build systems like python, rust, golang, etc.)

So no, dropping pkg-config support in favor of CMake is *never* an option IMNSHO. Apparently the arpack build systems live in a cuckoo world where they build pkg-config files but don't install them. Maybe you could submit a bug report asking them to install them anyway? And while you are at it, they could install CMake files from within autotools...

But switching to CMake would result in having to work around issues like:
- trying to install to /usr/lib64 which is a symlink and cannot be replaced
- building static libraries
- the aforementioned external makedepends just to add an inferior imitation of pkg-config
- having to manually install files that CMake does not install

I didn't realize it doesn't install it, that's a trivial thing to fix though. I'll try to get in contact with upstream. And I didn't mean to say we should _drop_ pkg-config in favor for CMake configs, but rather that there's a good reason projects provide these configs, and that's because pkg-config is quite the pain for scientific applications that are cross platform - I'm talking about downstream usage here. Either way, we don't have to discuss the merits of using CMake or autotools, but it stands that for cross platform scientific applications CMake has become common and many specialized scientific codes expect the ARPACK config to exist.

It's also worth noting that their current pkg-config is somewhat limited in use, since there's none present for the parallel ARPACK library libparpack.so, only for the serial one, libarpack.so. I'll try to see if that can be fixed. Installing CMake configs from autotools is rather complicated though. The main reason they exist (or their advantage if you will) is that they are generated from CMake exports and they know their dependencies. For ARPACK in specific, you have a dependency on LAPACK, and a statically linked ARPACK can have an arbitrary link requirement here since Intel MKL and so forth. Using pkg-config makes this very difficult (on macOS you have the accelerate framework for instance which has to be linked completely differently). With CMake configs, you don't have this issue as they link their dependencies as well - but for the same reason it's quite hard to generate these configs without being able to export the dependencies automatically.

As for Windows: It matters little what you or I think of the platform, or whether we use it, but rather that customers for commercial scientific codes often expect it to be an option for a platform. For example, do we use Linux exclusively at work, but all products we have can also run on Windows, because there's customer demand. You can call that insane all you want, but if I'm shipping a library, I can't build it with MinGW, and Intel MKL does not work with MinGW, either.

As for the CMake issue with lib64: I happen to be a CMake contributor, and never has anyone filed a bug report for that issue upstream. I've opened a Merge Request for fixing the LIBDIR default and the Java home path issue I saw worked around in vtk's PKGBUILD. While CMake is supposed to be working "everywhere", we can only fix bugs we are aware of - I've not run into this issue with the AUR packages I'm maintaining. If there's any other such issues or inconveniences, please file a bug report upstream, I'll look at them.

lib64 vs. lib depends on the platform you use, and in some cases, like Debian, it is actually /usr/lib/x86_64-linux-gnu/
See /usr/share/cmake-3.13/Modules/GNUInstallDirs.cmake for more details, note that it defaults to lib64 on a 64-bit system but special-cases Debian. On Arch, this directory is a compat symlink to enable runtime lookup, but you cannot overwrite it with a symlink...

Using -DCMAKE_INSTALL_LIBDIR=lib should handle this in the general case, as it does here, it is just something to remember when building.
It also only matters, I think, if a project uses include(GNUInstallDirs).

...

The default library target can be fixed by configuring arpack-ng using cmake -DBUILD_SHARED_LIBS=ON

...

As for the cmake config, I'm aware that cmake generates complex scripts for its foo-config.cmake scripts... but arpack is not doing that, it is using:
configure_file(arpack-ng-config.cmake.in "${PROJECT_BINARY_DIR}/arpack-ng-config.cmake" @ONLY)
install(FILES "${PROJECT_BINARY_DIR}/arpack-ng-config.cmake" DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/cmake") # find_package(arpack-ng)
configure_file(arpack-ng-config-version.cmake.in "${PROJECT_BINARY_DIR}/arpack-ng-config-version.cmake" @ONLY)
install(FILES "${PROJECT_BINARY_DIR}/arpack-ng-config-version.cmake" DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/cmake")


And the config file in question, what does it actually set? It sets the strings:

@CMAKE_INSTALL_PREFIX@/include/arpack
@CMAKE_INSTALL_PREFIX@/lib/libarpack.a
@CMAKE_INSTALL_PREFIX@/lib/libarpack.so
@CMAKE_INSTALL_PREFIX@/lib/libparpack.a
@CMAKE_INSTALL_PREFIX@/lib/libparpack.so

The version file additionally sets:
set(PACKAGE_VERSION "@arpack_ng_VERSION@")

So there is no reason, if they are intending to use such a primitive cmake config, that it cannot be installed from autotools too. It's frustrating when this doesn't just work by default. :/

You're right, it is indeed trivial to fix the non-installation of the pkg-config files. It's just that when you try to move to installing arpack using cmake, there are all of a sudden a *bunch* of trivial things that you need to fix.

Okay: apparently this is already known upstream by arpack-ng:
https://github.com/opencollab/arpack-ng/issues/63
https://github.com/opencollab/arpack-ng/pull/203

So they should be installing the pkg-config file regardless.

It is observed there that the currently generated pkg-config file for the cmake build is quite broken as it does not generate Libs.private:

Thanks for reporting, I'll look into adding a working .pc file, while waiting for upstream.

https://github.com/opencollab/arpack-ng/commit/1dab774991d3dd9c77199e630bc2c26e03160b47

In git master, autotools will now provide the cmake files. Yay. ;)
There is work to get the cmake build to install the .pc as well, but that is not done yet.

Hopefully with the next release upstream, everyone will have their preferred link mechanism no matter what their personal preference in build tools are; in the meantime, our package is already guaranteed to get cmake files as soon as we bump the pkgver.

Enabling icb is a different question, and will require modifying the PKGBUILD to begin providing.

Is there anything you think should be done with this issue right now, apart from waiting for upstream to make the next release?

In that case, adding --enable-icb to the PKGBUILD would be the only thing on Arch's end that needed doing now. This provides the C interface and the headers.

Added --enable-icb. Thanks for the suggestion. The updated package will appear in [community] shortly.