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
$)
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
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
