"Garth N. Wells" <[email protected]> writes: >> How do you ensure that you find the correct shared versus static >> libraries? Does the above really work for static? >> > > Yes, as far as I've tested. The complication is that a user code that > links to library A, where library A links to PETSc, needs a > find_package(PETSc) call in the user CMake file.
You must admit that "complication" is Trump-level insanity. Should linking to PETSc require the caller to find_package(every transitive dependency of PETSc)? Only a user that *calls* PETSc themselves should need to know about PETSc to link. Any package/configuration system that can't do that is broken. At least pkg-config has --static which (in principle) finds these transitive dependencies, as does libtool *.la files. > I don't understand CMake magic, but my limited understanding is that > > target_link_libraries(mylib PUBLIC PETSc::petsc) > > creates a mylib.cmake file which has a place holder for PETSc::petsc, > which the application CMake file provides provides > (https://cmake.org/cmake/help/v3.5/manual/cmake-packages.7.html#creating-relocatable-packages). How do you find the right one? All the complexity bubbles up to the user? >> In another thread, people are saying that PETSc should write a >> petsc-config.cmake that just passes flags "-L/path/to -lfoo" instead of >> fully-resolved library names (at least for static libraries). >> > > Doesn't that make it hard to switch between PETSc versions without > rebuilding? And won't it break relocatable builds? -L has nothing to do with run-time dependencies. This form does the right thing (assuming suitable libraries are available) when the user links statically or dynamically. One irritating feature of CMake is that find_library resolves full paths, but has no idea whether the library will be needed for static or dynamic linking (in fact, a project might want to link both ways). Last I checked, most of the built-in modules are broken for static linking. > The 'right' fix for a petsc-config.cmake would be the new-style CMake > imported targets to make things relocatable. I didn't care about any > of this until adding a conda-forge package, where a package is built > on a CI system and life is easier if builds can be relocated. What exactly does "relocated" mean? The CMake page just says they don't reference build directories that might not exist on the target machine. The -L options certainly have nothing to do with that. Does it actually mean that the install can be literally moved to any path with zero modifications and everything continues to work correctly?
signature.asc
Description: PGP signature
