[cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form

[Alan W. Irwin]

To temporarily work around some bugs in cmake-d support for the D
language case, I modified our normal use case for PLplot linking
between our D examples and D binding.  And that lead to the peculiar
result mentioned on the subject line which I have now also confirmed
for the Fortran language.  (So I presume this result holds both for
externally supported languages such as D and languages officially
supported by CMake such as Fortran.)

The PLplot Fortran examples link to the PLplot Fortran binding library
whose target name is PLPLOT::plplotfortran.  And PLplot uses
non-transitive linking on my (Linux, Debian Buster) platform.

So in the shared library build case, if I link the Fortran examples
using my normal method:

target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib PLPLOT::plplotfortran)

the resulting link command for our x00f example (and similarly for all
the rest) is

[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran && /home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran   -O3 -Wuninitialized -Wunused CMakeFiles/x00f.dir/x00f.f90.o  -o x00f -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f

which is the expected result (which mentions the link to the
plplotfortran library only in raw file format).  (N.B. I set the
environment variable FFLAGS="-O3 -Wuninitialized -Wunused" which
explains those special gfortran options.)

However, if I link the Fortran examples with

target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib $<TARGET_LINKER_FILE:PLPLOT::plplotfortran>)
add_dependencies(x${STRING_INDEX}f PLPLOT::plplotfortran)

the resulting link command for our x00f example (and similarly for all
the rest) is

[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran && /home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran   -O3 -Wuninitialized -Wunused CMakeFiles/x00f.dir/x00f.f90.o  -o x00f  -L/home/software/plplot/HEAD/build_dir/bindings/fortran -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran ../libplfortrandemolib.a -lplplotfortran ../../bindings/fortran/libplplotfortran.so.0.2.0 
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f

I expected that the result would simply link to the plplotfortran
library in "-L/home/software/plplot/HEAD/build_dir/bindings/fortran
-lplplotfortran" form so that redundant mention of the *same* library
in raw file form (../../bindings/fortran/libplplotfortran.so.0.2.0)
was a surprise to me.

My guess is this is actually an expected (albeit peculiar) result for
the above use case due to the existing general design of CMake
language support, but I thought I had better mention this result here
in case it is due to a bug in that support.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________