[petsc-dev] Problem with petsc.pc when configured with --with-single-library=0

[Jed Brown]

"Garth N. Wells" <gnw20 at cam.ac.uk> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170304/41ecf905/attachment.sig>