[CMake] FindThreads: the odd one out?

Alexander Neundorf a.neundorf-work at gmx.net
Fri Sep 4 15:55:30 EDT 2009


On Sunday 30 August 2009, Philip Lowman wrote:
> On Fri, Aug 28, 2009 at 4:29 AM, Marcel Loose <loose at astron.nl> wrote:
> > Hi all,
> >
> > Up till now I've been using the not officially supported and released
> > FindPthreads.cmake macro to check for the presence of pthreads. However,
> > the maintainer of that macro wrote (a comment in Mantis) that he would
> > drop support for FindPthreads in favor of the more general and
> > officially supported FindThreads.cmake macro.
> >
> > However, I have some difficulty understandig how to properly use
> > FindThreads.cmake. Contrary to most FindXXX macros it does not set
> > THREADS_INCLUDE_DIR and THREADS_LIBRARY. It does set some *_INIT
> > variables, but I thought that *_INIT variables were only used by CMake
> > itself to preset compiler and linker flags, and that these were not to
> > be used outside.
> >
> > Could someone shed a light on this?
>
> I could also use some illumination on this.  I get that you're supposed to
> use CMAKE_THREAD_LIBS_INIT with target_link_libraries() because libpthread
> isn't always called "libpthread", but it also looks like
> CMAKE_THREAD_LIBS_INIT can also be set to "-pthread" in the event the
> system doesn't have a pthread library and it's supposed to be a compile
> definition thing...???  If so, why one variable instead of two?  Also what
> systems does this happen on?
>
> I'm not sure if anyone is actually using the pthreads-win32 stuff I wrote

This one: http://sourceware.org/pthreads-win32/ ?
3 years ago I was using it (to make that software easily portable).

I also think FindThreads.cmake is somewhat strange, doesn't it basically load 
the thread library of the current platform ? That means that you get 
different APIs on different platforms and therefor need different code ?

Alex


More information about the CMake mailing list