What install do we want / need ?

[fghoussen]

What install do we want / need ? What should be the standard way to install arpack-ng?

CMake regular install looks like this:

/tmp/tstCMakeInstall/local
├── include
│   └── arpack-ng
│       ├── arpackdef.h
│       ├── arpackicb.h
│       ├── debugF90.h
│       ├── debug.h
│       ├── statF90.h
│       └── stat.h
└── lib
    └── x86_64-linux-gnu
        ├── cmake
        │   └── arpack-ng
        │       ├── arpackng-config.cmake
        │       └── arpackng-config-version.cmake
        ├── libarpack.so -> libarpack.so.2
        ├── libarpack.so.2 -> libarpack.so.2.1.0
        ├── libarpack.so.2.1.0
        ├── libparpack.so -> libparpack.so.2
        ├── libparpack.so.2 -> libparpack.so.2.1.0
        ├── libparpack.so.2.1.0
        └── pkgconfig
            ├── arpack.pc
            └── parpack.pc

CMake LIBSUFFIX=64 install looks like this:

/tmp/tstCMakeInstall/local
├── include
│   └── arpack-ng
│       ├── arpackdef.h
│       ├── arpackicb.h
│       ├── debugF90.h
│       ├── debug.h
│       ├── statF90.h
│       └── stat.h
└── lib
    └── x86_64-linux-gnu
        ├── cmake
        │   └── arpack-ng
        │       ├── arpackng-config.cmake
        │       └── arpackng-config-version.cmake
        ├── libarpack64.so -> libarpack64.so.2
        ├── libarpack64.so.2 -> libarpack64.so.2.1.0
        ├── libarpack64.so.2.1.0
        ├── libparpack64.so -> libparpack64.so.2
        ├── libparpack64.so.2 -> libparpack64.so.2.1.0
        ├── libparpack64.so.2.1.0
        └── pkgconfig
            ├── arpack64.pc
            └── parpack64.pc

CMake ITFSUFFIX=ILP64 install looks like this (note include directory name changes are #define in headers changes):

/tmp/tstCMakeInstall/local
├── include
│   └── arpack-ngILP64
│       ├── arpackdef.h
│       ├── arpackicb.h
│       ├── debugF90.h
│       ├── debug.h
│       ├── statF90.h
│       └── stat.h
└── lib
    └── x86_64-linux-gnu
        ├── cmake
        │   └── arpack-ng
        │       ├── arpackng-config.cmake
        │       └── arpackng-config-version.cmake
        ├── libarpackILP64.so -> libarpackILP64.so.2
        ├── libarpackILP64.so.2 -> libarpackILP64.so.2.1.0
        ├── libarpackILP64.so.2.1.0
        ├── libparpackILP64.so -> libparpackILP64.so.2
        ├── libparpackILP64.so.2 -> libparpackILP64.so.2.1.0
        ├── libparpackILP64.so.2.1.0
        └── pkgconfig
            ├── arpackILP64.pc
            └── parpackILP64.pc

CMake ITFSUFFIX=ILP64 LIBSUFFIX=64 install looks like this:

/tmp/tstCMakeInstall/local
├── include
│   └── arpack-ngILP64
│       ├── arpackdef.h
│       ├── arpackicb.h
│       ├── debugF90.h
│       ├── debug.h
│       ├── statF90.h
│       └── stat.h
└── lib
    └── x86_64-linux-gnu
        ├── cmake
        │   └── arpack-ng
        │       ├── arpackng-config.cmake
        │       └── arpackng-config-version.cmake
        ├── libarpack64ILP64.so -> libarpack64ILP64.so.2
        ├── libarpack64ILP64.so.2 -> libarpack64ILP64.so.2.1.0
        ├── libarpack64ILP64.so.2.1.0
        ├── libparpack64ILP64.so -> libparpack64ILP64.so.2
        ├── libparpack64ILP64.so.2 -> libparpack64ILP64.so.2.1.0
        ├── libparpack64ILP64.so.2.1.0
        └── pkgconfig
            ├── arpack64ILP64.pc
            └── parpack64ILP64.pc

Note that:

• there is always only one arpackng-config.cmake: it doesn't behave like arpack*.pc files: do cmake and pc files must behave the same way?

• having several arpack*.pc files means you need to know which one you need to use: this may change (code change) the way you call pkg-config. note that some packages work this way: mkl-intel provides several pc files, and, to use mkl you must know which mkl flavor you want to use.

• autotools (configure) does not provide cmake files (all of the above is generated by CMake).

If you have to maintain only "one local directory" for all flavors of arpack-ng, you may not be able to cope with everything.
But using module-environment (module avail; module load what-I-need), you don't have to bother with this: the admin who installed it can hide all this for you.

I have no idea what standards are on the topic (I use module-environment): if you know what's best to do, speak-up!

[mmuetzel]

That's only one reference point. But here is what OpenBLAS is doing with respect to 32-bit vs. 64-bit Fortran integers:
IIUC, they use only one config flag to switch between the two. It is called INTERFACE64. It affects both the Fortran integer size and file names.
When set to 0 (default), the 32-bit Fortran integer version is built. The "base" names are used for files and installation folders.
When set to 1, the 64-bit Fortran integer version is built. 64 or _64 is appended automatically to some files and folders. The packager/builder doesn't have an option to change these suffices.
Additionally (and independent of the Fortran integer size), it is possible to define an additional library prefix and/or suffix. These prefix and suffix only apply to the libraries (and not to the .pc and .cmake files).

The installed files for both versions can be seen, e.g. at the bottom of these pages (without the optional library prefix or suffix):
https://packages.msys2.org/package/mingw-w64-x86_64-openblas?repo=mingw64
https://packages.msys2.org/package/mingw-w64-x86_64-openblas64?repo=mingw64

ARPACK doesn't need to follow the same logic. But these switches seem to work for them.

The advantage of their approach is imho that the name of both package "flavors" is predictable (for pkg-config or cmake users) independent of the distribution.

[mmuetzel]

IIUC, they append 64 to openblas (or OpenBLAS) in both cases.
I believe it is a convention (or is it a requirement?) that the folder name is repeated as the prefix in the *Config.cmake (or *-config.cmake) file. IIUC, these files must end with one of these specific suffices or they aren't recognized by cmake. So, I'd guess they are pretty consistent with these file names.

But you are right: ARPACK could (and should?) probably also change the .cmake file names accordingly.

I'm no longer sure if LIBSUFFIX should be inserted in the file name for the .pc files (now that there is ITFSUFFIX which better serves to make this distinction imho).

One possible way could be to set ITFSUFFIX to an empty string if INTERFACE64 isn't set, and to "64" otherwise.
Then also insert the ITFSUFFIX in the generated .cmake files and installation folder, and get rid of the LIBSUFFIX in the .pc file names.

Do you think that this is reasonable?

[mmuetzel]

Fwiw, OpenBLAS inherited that naming convention from upstream Netlib BLAS/LAPACK:
Reference-LAPACK/lapack@5dd47be

[mmuetzel]

I opened PR #360 for a proof-of-concept how a standardized suffix for 64-bit Fortran integers could be implemented.

[fghoussen]

LIBSUFFIX enables to share the same include directory, when possible, for any possible flavors (32, 64, ppc [?], ...): this is the simplest way to customize the install directory in most cases (say 99%), and, only when needed (for instance, on 64-bits arch lib stands for lib64 so you don't even need to use LIBSUFFIX).

ITF64SUFFIX enables to handle different include directories: this is needed (headers are not the same) but it's a very very uncommon case (say 1%), so there is a specific suffix for this specific case.

I don't like "automatic" and "mixing" stuffs/settings: they never do what you want and you can't unplug them! :( I prefer people to understand/know/control what they do why and where! :)

For all these reasons, I don't think #360 is a good move. But if you like, following LAPACK and OpenBLAS we may have a different .cmake per arpack-ng flavor (IIUC what LAPACK and OpenBLAS do): something like #362?

[mmuetzel]

Imho, LIBSUFFIX should only do what its name suggests: Add a suffix to the libraries (not the .pc or .cmake files).
I understand that you'd like to be as flexible as possible with the ITF64SUFFIX. But - like I tried to explain also in other PRs - it would be very nice if the 64-bit Fortran indexing version would be universally identifiable. It might be close to impossible to refer to them effectively if every distribution decides to give them a different name.
You might be correct that libraries with 64-bit Fortran integers aren't very common (yet). But it looks like, with more powerful hardware and more memory available in many systems, they become more and more used in certain areas.
BLAS/LAPACK and OpenBLAS adapted to that trend recently. It is very likely that other numeric libraries are going to follow (if they haven't already). But as long as not all numeric libraries and all applications that are using them have moved to 64-bit Fortran integers, we'll need to be able to install those libraries in both variants at the same time.

This is orthogonal to multi-arch distributions (that use, e.g., lib32 for i686 and lib64 for x86_64 ). Both of the variants we talk about here are for the same architecture.

If BLAS/LAPACK and OpenBLAS opted to christen their packages that are built with 64-bit Fortran integers with a fixed name, it might make sense for ARPACK to do the same.

I don't think that #362 would help to avoid that possible mess.

[fghoussen]

Not convinced by "automatic" stuff as explained. We may set a relevant default value for LIBSUFFIX.

Add a suffix to the libraries (not the .pc or .cmake files).

Lots of packages add suffixes to pc files (MKL and others)

[mmuetzel]

Please, let me try to describe a use-case that would be nice if ARPACK supported it out of the box:
The thing that starts all the "complications" is that libraries that are built with a different size of Fortran integers aren't compatible to each other in general.
Let's assume that there is a (Fortran) library A that depends on another (Fortran) library B. Both libraries can be compiled with 32-bit Fortran integers and 64-bit Fortran integers (variants 1 and 2). The goal is to install both versions at the same time and allow the build rules of library A to select the matching variant of library B in their build rules.
To achieve that goal, the library A could have configuration flags to built it either using 32-bit or 64-bit Fortran integers. Depending on that switch, it could look for either library B1 or B2.
To make this a bit more tangible, let's say library A is ARPACK and library B is OpenBLAS. OpenBLAS can already be installed in both variants. The name of variant 1 is openblas and the name of variant 2 is openblas64. In that case, the build system of ARPACK could check for the LDFLAGS to build with variant 1 of OpenBLAS with, e.g., pkg-config --libs openblas. Similarly, it could check for the LDFLAGS to build with variant 2 of OpenBLAS with pkg-config --libs openblas64. The build system could do that automatically dependent on whether it was configured for 64-bit Fortran integers or not. The build rules do not need to contain any more logic and the user/packager that builds ARPACK in any of these variants wouldn't need to prepare the environment either (e.g., no need to change PKG_CONFIG_PATH or anything else).
I chose to use pkg-config in this example because it is a bit easier to talk about. But the same would be possible with cmake.
This is only possible with OpenBLAS because their .pc and .cmake files are installed at the default locations and they have predictable names on all distributions.

Imho, it would be nice if ARPACK would allow to do something similar. So, in the above example ARPACK would be library B and some other project would be library A.
If I understand correctly that would require that:

1. It would be necessary to install both variant 1 and variant 2 at the default prefix at the same time.
2. The .pc and .cmake names of both variant 1 and variant 2 would need to be different from each other.
3. The .pc and .cmake names of both variant 1 and variant 2 would need to be predictable (independent of the distribution).

As far as I can tell, these requirements aren't met currently (apart from partly 1.).

I hope it would be possible to adapt ARPACK so that it could meet those requirements.

PS: The openblas64 package is pretty new. And not many distributions package it at the moment. So probably, ARPACK can't rely on that mechanism currently. But that can change in the future...

[fghoussen]

Got your point: could make sense. Don't know what standards are, not sure how to get there.
To me, looks like setting a relevant default suffix value could be enough?

[mmuetzel]

Don't know what standards are,

Both Netlib BLAS/LAPACK and OpenBLAS opted to add the suffix "64" to the package name to distinguish between the two variants. That looks like it could be a "de-facto standard" now.

not sure how to get there.
To me, looks like setting a relevant default suffix value could be enough?

I tried to do changes that would meet the three requirements above in PR #360. But that PR doesn't apply any more.
Please, let me know if you think that this approach is reasonable. In that case, I could try to rebase that PR on the current head.