Re: [cmake-developers] Possible feature request concerning conditional linking support by generator expressions

[Brad King via cmake-developers]

On 9/24/19 5:02 PM, Alan W. Irwin wrote:
> I. Possible feature request
> 
> After reading through the generator-expression documentation at
> 
> it appears for my use case (see below) I need generator expressions of
> the form
> 
> $<$>:-pthread>
> $<$:-pthread>
> $<$:-Xcc-pthread>
> $<$:libbasename> (where libbasename is likely pthread)
> 
> where I guess (since I am pretty much a newbie with regard to detailed
> generator expressions) they would all be combined together in a list
> for a library target INTERFACE_LINK_LIBRARIES property.

I've opened an issue for that proposal and the associated use case:

* https://gitlab.kitware.com/cmake/cmake/issues/19757

-Brad
-- 

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

Re: [cmake-developers] Possible feature request concerning conditional linking support by generator expressions

[Alan W. Irwin]

On 2019-09-24 14:02-0700 Alan W. Irwin wrote:

[...]

I. Possible feature request

After reading through the generator-expression documentation at

it appears for my use case (see below) I need generator expressions of
the form

$<$>:-pthread>
$<$:-pthread>
$<$:-Xcc-pthread>
$<$:libbasename> (where libbasename is likely 
pthread)




To follow up, I have just been informed on one of the dmd mailing
lists that the dmd developers have implemented an option in a
pre-release version of dmd 2.088.0 that will change the semantics of
-L so that dmd with that option (-preview=noXlinker) will interpret
-L-pthread as a request to pass that -pthread option on to the C
compiler used internally by dmd for linking.  So when I implement this
fixed -preview=noXlinker option in PLplot's fork of the cmake-d dmd D
language support it appears the above dmd example of my possible
feature request above would change to


$<$:-L-pthread>

And similarly I would use -L-pthread for dmd in my proposed workaround for
the lack of such generator-expressions right now.

In sum, some substantial uncertainty about how to handle the -pthread
option for the dmd case is now gone, but the question still persists
about whether I will always have to use the proposed messy workaround
(which requires building an extra variant of the PLplot library) or
whether I can look forward to someone implementing the above generator
expressions which would provide a neat solution to the -pthread
linking issue I have described.

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

[cmake-developers] Possible feature request concerning conditional linking support by generator expressions

[Alan W. Irwin]

Sorry for the long post, but my use case is complex, and there are
several possible solutions to the problem presented by that use case
which add to the length of this.  So to help keep your reading
organized, this post is separated into three sections which are (I.) a
possible feature request explaining what I think I need in an ideal
world, (II.)  my use case, and (III.) possible solutions to the
-pthread and D problem presented by that use case (including you guys
implementing this feature request).

I. Possible feature request

After reading through the generator-expression documentation at

it appears for my use case (see below) I need generator expressions of
the form

$<$>:-pthread>
$<$:-pthread>
$<$:-Xcc-pthread>
$<$:libbasename> (where libbasename is likely pthread)

where I guess (since I am pretty much a newbie with regard to detailed
generator expressions) they would all be combined together in a list
for a library target INTERFACE_LINK_LIBRARIES property.

It appears such generator expressions are not implemented now and
there is no other way to use generator expressions to deal with my use
case, but if you think this feature would generally be worthwhile once
you have considered my use case and others who might have already
expressed a need for this functionality, I would be willing to make a
formal feature request on the bug tracker for this
generator-expression capability.

II. Use case:

The PLplot build system is currently in an inconsistent mess with our
various device drivers that depend on various external libraries
specifying the thread library in a variety of ways.  So my plan is to
figure out how to make the thread library results delivered by a
number of different find modules consistent with the Thread::Thread
target result returned by find_package(Threads), and the rest of this
discussion considers one particular configuration where that work
has already been done.

I have already done that work for our xwin device driver and all the
PLplot libraries are now built with the PRIVATE option for
target_link_libraries.  So here is a simplified result for the static
case (where that device code becomes part of the plplot library) when
only that device has been enabled:

-- DEBUG: For target=Threads::Threads and property=INTERFACE_LINK_LIBRARIES, 
the value of the property is -pthread
-- DEBUG: For target=PLPLOT::plplot and property=INTERFACE_LINK_LIBRARIES, the value of the property is 
/usr/lib/x86_64-linux-gnu/libSM.so;/usr/lib/x86_64-linux-gnu/libICE.so;/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so;$;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libshp.so;/usr/lib/x86_64-linux-gnu/libfreetype.so;$;$;$
-- DEBUG: For target=PLPLOT::plplotdmd and property=INTERFACE_LINK_LIBRARIES, the 
value of the property is $

Note, PLplot has its own recently developed fork of the cmake-d
project that works well for D language support on Linux for all three
of the dmd, ldc2, and gdc D compilers, and preliminary results on
Darwin for dmd are good as well. However, there is one remaining D
issue considering the -pthread link option delivered by the above
combined INTERFACE_LINK_LIBRARIES to the D example builds via

target_link_libraries(x${STRING_INDEX}d PLPLOT::plplotdmd PLPLOT::plplot 
${MATH_LIB})

For the static case that example build combines C and D objects from
the plplot and plplotdmd libraries and the D code making up the D
example into the x${STRING_INDEX}d executable.  And the problem is
that although the gdc compiler understands the -pthread *compiler
option* that is used for linking the executable, the dmd and ldc2
compilers do not understand that option.  Fortunately they both link
by using an underlying C compiler (rather than calling ld directly),
and in the ldc2 case you can specify the -pthread option to the
underlying C compiler used for linker with the -Xcc-pthread option.
But you cannot currently do that with dmd (although there are requests
on their bug tracker of simply following ldc2 in this regard).  So for
the dmd case we need (at least for now) to specify the library with
its "pthread" basename (which will be translated by the D language
support into the -L-lpthread option that the dmd compiler understands)
or as the full pathname of the library (which will be translated by D
language support into the -Lfullpathname form that the dmd compiler
also understands).

III. Possible solutions to the -pthread and D issue presented by this use case.

* Do not set THREADS_PREFER_PTHREAD_FLAG so the Threads find module
  delivers a library rather than the -pthread compiler option used for
  linking.  Although that appears to work well of my Debian Buster
  platform (once 
  is worked around for older versions of CMake) it is not a generally
  recommended solution since apparently on some platforms the -pthread