cmake build doesn't install arpack.pc

[rathann]

After configuring arpack-ng 3.5.0 using cmake, make install doesn't install the arpack.pc file. Indeed, the relevant lines are commented out in CMakeLists.txt:

configure_file(arpack.pc.in arpack${LIBSUFFIX}.pc @ONLY)

#install(FILES ${CMAKE_CURRENT_BINARY_DIR}/arpack${LIBSUFFIX}.pc
#    DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)

[dpo]

#44

[sylvestre]

oups, sorry, it's not actually fixed

[rathann]

I'm afraid it isn't:
https://github.com/opencollab/arpack-ng/blob/master/CMakeLists.txt#L433
is still commented out in current git master

[sylvestre]

@turboencabulator do you know why this is still commented?

[turboencabulator]

Check out the lines further up that are also commented. We need to populate things like the package version and the flags to link against blas/lapack. I don't know how to do this using cmake. Until those get filled in appropriately, the file it generates will not be useful.

[fghoussen]

*.pc files are autotools, *.cmake are cmake equivalent. For me, cmake is not supposed to provide *.pc (<=> autotools would be supposed to provide *.cmake). If you want pc files, just use autotools.

[10110111]

*.pc files are autotools

Actually pkg-config, not autotools. The former is independent from the latter. Unlike autoools, pkg-config is not even GNU.

If you want pc files, just use autotools.

This view is quite harmful. It forces the programs which depend on ARPACK to completely ignore both CMake modules and pkg-config and simply use home-grown detection — or jump through hoops and try CMake module, if it doesn't work, then pkg-config, if it doesn't work, something else... A mess.

I'd suggest installing both (or whatever you have) in both modes to ease the life of ARPACK users. Then the users will simply use the method they prefer without asking how the target OS has configured its ARPACK package.

[fghoussen]

Users should install both with autotools / cmake so this issue can be closed : no issue here ! Cmake / autotools should install only files they are responsable of.

[10110111]

Users should install both with autotools / cmake so this issue can be closed : no issue here ! Cmake / autotools should install only files they are responsable of.

Erm, that sounds strange. Not only are there two build systems in ARPACK (which is already redundant), but the users should compile the library twice simply to get all the detection/configuration methods supported by it installed... And once again, pkg-config has no relation with autotools.

All this sounds really weird to me, what am I missing?

[fghoussen]

Sounds as logical as minimal: be responsible of your stuff only ! Lots of soft do that : check out hdf5 for instance

[rathann]

Surely maintaining two different build systems is more work than one (you have to make changes in two places). Also, having to build twice using different build systems to get all the pieces sound illogical to me. If hdf5 does that then it's a special snowflake. Most projects I know use either autotools or cmake, but not both and if they use cmake, they generate .pc files, too. .pc files are for pkg-config (or it's replacement pkgconf) and they don't depend on either autotools or cmake (and vice versa).

[sylvestre]

I agree. We should aim at removing autoconf support in the next major release of arpack-ng. Sylvestre

[fghoussen]

maintaining two different build systems is more work than one (you have to make changes in two places)

Sure, it's true for changing version number, soname, ...

We should aim at removing autoconf support in the next major release

The decision is yours !

My understanding (not 100% sure !) is that:

• autotools decided to rely on pc files (provided by another package : pkg-config)

• cmake decided to handle things by himself (cmake files)

• in an ideal world: if you install with autotools/cmake, you do not need cmake/pc files

• in real world, users "don't want to bother" with "many" things (environment being the first one !)... So pc or cmake files are not found (in 99.99% of cases, environment is just not set, or, messy / corrupted - all build systems rely on environment : this is no magic !). This may (?) be why some software provide both cmake and autotools (to increase chances package to be found ?). This may also be why cmake piggy backs on pc files when *.cmake are not found (note that this is a fallback situation where you do not want to be : 1) when cmake files are provided, not finding them means the environment is wrong 2) you can set more info [extra variables] in cmake files)... And yes: you need to compile twice, but, it's only at install time before to set up a module file for instance (is this so bad ? in real world, not that much !... And may save admin sys from many dummy users)

• cmake/autotools do not do always the same thing the same way: for instance, I guess there is no equivalent for make distcheck in cmake, cmake packaging is comes with a different "style" than autotools, autotools has no equivalent for CDash (which may be convenient), not sure if you can cross-compile with cmake (maybe ?), ....

• sometimes, on machines you do not rule (no root privileges), the version of autotools/cmake is too old to work but fortunatelly, the other one works and saves you ! :D

• not sure there is a counterpart in cmake for autotools make dist-check (which may reveal architecture oriented problems)

Not sure there is a yes-or-no answer here.

To me, autotools must be dropped when you need to write some m4 to find exotic stuffs (GPU, FPGA): m4 is so cryptic that nobody can maintain this !... So dropping autotools seems healthy :D

[10110111]

CMake does support cross-compilation, see their documentation Wiki.

[fghoussen]

Not sure there is a yes-or-no answer here.

@rathann : does not mean no, I you need this feel free to PR it ! I guess (?) @sylvestre would take that

[sylvestre]

Sure, let's do it.
And bump the version to 3.8

[turboencabulator]

I haven't been following this conversation and can't tell what has been decided, but I need to correct some of the comments above.

The purpose of arpack.pc and CMake's equivalent is to help out packages that depend on this one. pkg-config is stand-alone. To me, it looks like CMake is trying to create its own competing standard that is less functional and really pointless if CMake can use pkg-config directly.

The arpack-ng-config.cmake stuff is tied to CMake. If my project links to arpack, then my project has to use CMake to get any benefit from these files. With arpack.pc, my project doesn't have to be tied to any particular build system to get the benefit. I can write a makefile by hand that calls pkg-config if I want.

Suppose my project has an optional dependency on arpack and wants to check if arpack exists so it can use it if it does exist. I know pkg-config can do this, but I don't know how to do it in CMake. What happens if my CMake script tries to include the arpack detection stuff, but arpack and the arpack-ng-config.cmake files aren't installed? If it breaks my CMake script, then there is no benefit to having arpack install those CMake files at all; I should write my own arpack detection, or hope that arpack.pc is installed so CMake can try detecting it that way instead.

arpack.pc should be installed regardless of which build system you used to build your arpack package. We need to fix the CMake scripts to create and install this file correctly, then consider whether the arpack-ng-config.cmake stuff is still necessary. Autotools has nothing to do with this, and removing it would not solve anything.

[fghoussen]

Not sure there is a yes-or-no answer here.

To me, "yes" or "no" could both be the correct answer !...

Why "no" could be the correct answer :

What happens if my CMake script tries to include the arpack detection stuff, but arpack and the arpack-ng-config.cmake files aren't installed?

It does not happen: *.cmake files are always installed by CMake. They enable CMake users to use the find_package mechanism so I guess it's a good thing to keep (natural way to do thing for CMake users who will choose to install arpack-ng... Likely with CMake, not autotools !). But, then, why to provide *.pc file, you are not supposed to need it anymore (in "theory"... But possibly not in "real world" situations !)

arpack-ng-config.cmake files aren't installed? If it breaks my CMake script, then there is no benefit to having arpack install those CMake files at all;

In 99% cases, your environment is wrong !... And CMake can not be blamed for that.

Why "yes" could be the answer :

I can write a makefile by hand that calls pkg-config if I want.

You are right ! I do not use Makefiles for so long that I forgot this case ! :D

if CMake can use pkg-config directly.

Yes, it can ! An example here :

arpack-ng/CMakeLists.txt

Line 68 in dfc8abd

if (NOT Eigen3_FOUND) # If not found, piggy-back pkg-config files.

To me it depends on "your philosophy" : are you CMake only ? If so you don't need *.pc files (as you decide to rely on *.cmake files via find_package). Are you autotools only ? If so, you don't need *.cmake files. Or do you like (or are you compelled ?) to mix CMake/autotools flavors ?... If so you need both: that's why good admin sys (!) I know do install packages with both autotools and CMake : to maximize chances users will have to "find" what they need.

It's never clear who you "want" to be, and, who you "can" be in real world situation (= real world messy/hurry users working on real world dirty-installed computer).

Check out the lines further up that are also commented. We need to populate things like the package version and the flags to link against blas/lapack. I don't know how to do this using cmake. Until those get filled in appropriately, the file it generates will not be useful.

I guess this could work but I can't test it... And I do not PR something I can't test ! :D

>> git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1af53ce..a98eb51 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -625,13 +625,11 @@ set(includedir \${prefix}/${CMAKE_INSTALL_INCLUDEDIR})
 set(PACKAGE_NAME ${PROJECT_NAME})
 set(PACKAGE_VERSION ${arpack_ng_VERSION})
 set(PACKAGE_URL "https://github.com/opencollab/arpack-ng/")
-# TODO: Fill these in with something appropriate.
-#set(LAPACK_LIBS)
-#set(BLAS_LIBS)
+set(LAPACK_LIBS ${LAPACK_LIBRARIES})
+set(BLAS_LIBS ${BLAS_LIBRARIES})
 configure_file(arpack.pc.in arpack${LIBSUFFIX}.pc @ONLY)
-#install(FILES ${CMAKE_CURRENT_BINARY_DIR}/arpack${LIBSUFFIX}.pc
-#    DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
-
+install(FILES ${CMAKE_CURRENT_BINARY_DIR}/arpack${LIBSUFFIX}.pc
+        DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
 
 # We don't want this to run on every build.
 option(COVERALLS "Generate coveralls data" OFF)

@rathann : you could (??) test that... And discover that it's not yet doing what you want. If you get something to work, you could PR it !...

[rathann]

@fghoussen Thanks for the initial patch. It looks like CMakeLists.txt needs quite a few more fixes. I'll send a PR soon.

[rathann]

I still can't use cmake due to issue 18942, though.

[eli-schwartz]

arpack.pc should be installed regardless of which build system you used to build your arpack package. We need to fix the CMake scripts to create and install this file correctly, then consider whether the arpack-ng-config.cmake stuff is still necessary. Autotools has nothing to do with this, and removing it would not solve anything.

The arpack-ng-config.cmake stuff may or may not be necessary, but if it is going to be distributed at all, then just as cmake should distribute universal pkg-config files, autotools should distribute custom cmake files.

The user should not care how arpack was built when deciding which build system to use, and this goes both ways. If cmake projects are expected to use *-config.cmake files, then they should always be available. If they cannot depend on e.g. Linux distributions building with cmake, then even cmake users will be forced to use the pkg-config files, which goes against the purpose of installing the cmake files at all.

I would like to note that the cmake files are literally just configuring the information which in autotools is the ${prefix}, into a prepared file. So this should be quite doable to generate from any build system.

[fghoussen]

Fixed by #350