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

[Garth N. Wells]

On 5 March 2017 at 06:15, Jed Brown <jed at jedbrown.org> wrote:
> "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.

We need this search for PETSc because we expose PETSc in the public
interface - users can call PETSc themselves. Most dependencies do not
appear in the public interface, in which case a user doesn't need to
to worry about them when building their own application.

Jed, I'm not going to debate the topic. I'm not knowledgable enough,
or interested enough in the details. My original message was that
PETSc.pc was broken, and I'm grateful that it's been fixed. I do think
a good PETSc.pc file would be helpful to users.

Garth

 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?