[CMake] Reason for deprecation of GenerateExportHeader ?
Hello, the documentation page https://cmake.org/cmake/help/v3.11/module/GenerateExportHeader.html has the mention : > This function is deprecated. Set the target properties CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN instead. Why is that so ? I don't know any library that would export either all or none of its symbols ; functions & types of the public API must always be chosen manually by the author of the library anyways. The only use of CXX_VISIBILITY_PRESET is to set the visibility to hidden by default, so that code can then use the export macros defined by the generate_export _ header code to make specific symbols visible. Best, Jean-Michaël --- Jean-Michaël Celerier http://www.jcelerier.name -- 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
Re: [CMake] -std=c++17 vs -std=c++1y
Note that c++17 is c++1z. c++1y was C++14. --- Jean-Michaël Celerier http://www.jcelerier.name On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword < andrew.e.brownsw...@gmail.com> wrote: > Hi, > > Is there a way to get cmake 3.11 to emit 17 vs 1y when setting > CMAKE_CXX_STANDARD? I’m finding that it seems to be a common practice to > use the value of the preprocessor define __cplusplus (which is a date), and > the value differs depending on whether 17 or 1y is used (at least with > CLang). I haven’t figured out how to get cmake to emit -std=c++17, it > always seems to use 1y, which is causing problems with code that assumes > the __cplusplus date reflects the c++17 standardization date. > > Thanks, >Andrew > > -- > > 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 > -- 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
Re: [CMake] Removing Transitively Inherited Properties
For stuff like this one you could add -Wno-error afterwards to A's compile_options. --- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Feb 6, 2018 at 11:15 AM, Geogin Varghese wrote: > What is the recommended way of removing transitively inherited > attributes for a target. > > Example: > target_link_libraries(A PRIVATE B) > target_compile_options(B PUBLIC -Werror) > > How should the -Werror option be removed from target A. > -- > > 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 > -- 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
Re: [CMake] Building cmake: why is openssl linked?
https://cmake.org/cmake/help/latest/module/ExternalProject.html since CMake can download stuff, it needs to support https, hence SSL, hence OpenSSL Best, --- Jean-Michaël Celerier http://www.jcelerier.name On Sun, Jan 14, 2018 at 12:15 AM, Paul Smith wrote: > Hi all. > > I build CMake myself. I've noticed that on GNU/Linux by default cmake > will be linked with openssl and require these shared libraries to be > available at runtime. > > Why does cmake link with these libraries? I can't think of a reason it > might need them. What do I lose in functionality if I force > CMAKE_USE_OPENSSL to OFF during the build? > -- > > 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 > -- 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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. Not always, some people sometimes feel like doing it by hand from scratch with if(EXISTS ...). Sadly. On Tue, Aug 29, 2017 at 5:49 PM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: > > That's correct: > > > > find modules do what they want, and most do not pay attention to > > CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -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: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?
> Ok got it sorry to hear that certainly because, as soon as I hear
> something that would be useful somehow I end up needing it the next day.
> So sorry for us both.
>
> From what your are saying (and I will take your word for it) the CMake has
> a another problem in not implementing "inherited build properties"
> correctly. That is of course if that is what CMake is after with
> add_library( targ INTERFACE) in the first place.
>
>
I think that there is just no mechanism for "inherited build properties".
>From the docs (
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries),
INTERFACE targets seems to be meant for header-only libraries.
The "inheritance" mechanism in CMake is mainly setting variables in a given
folder, but this is imho not flexible enough, and leads to problems when
you want to use your library as a subfolder of another since you don't have
an easy way to overwrite "child" variables from a parent scope unless the
child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags
${CMAKE_CXX_FLAGS}") every time.
> Thanks for the heads up on yet more CMake does not do correctly.
>
> I am now climbing upon my "inherited build properties" soap box. It's
> kinda slippery up here.
>
> On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > Does that work for your needs?
>>
>> Sadly, no (but thanks!). While this is enough for the arguably common use
>> case of include directories, compile flags, etc... there are plenty of
>> things that won't work with this approach.
>>
>> e.g. none of this works for instance:
>>
>> project(foo)
>>
>> add_library(blah INTERFACE)
>> set_property(TARGET blah PROPERTY SUFFIX ".mxe")
>> set_property(TARGET blah PROPERTY CXX_STANDARD 14)
>> set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")
>>
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote:
>>
>>> So there is some odd replies in the cmake mailing list possibly responses
>>> to wrong message, but this looked like a response to mine even if the
>>> initial reply to bit is not right from Nicholas. Anywho here goes:
>>>
>>> @Jean-Michaël Celerier
>>>
>>> -- snip --
>>> >* - Says that custom functions such as add_{project}_library shouldn't be
>>> *used and function definitions should be used as little as possible. Except
>>> this just leads to extremely verbose CMakeLists where repeated properties
>>> are defined again and again and again.
>>> -- snip --
>>>
>>> Yes add_project_library were my own and in the process of being deprecated.
>>> These were geared directly at two problems in cmake.
>>>
>>> 1) They were used to get CMake to support the concept of "inherited build
>>> properties".
>>>
>>> 2) As you stated and is still a problem the verbosity of CMake. Where IMO
>>> much could be collaped into one call
>>>
>>>
>>> -- snip --
>>> I also never understood how to handle this.
>>> -- snip --
>>>
>>> I am afraid I don't ultimately have the answer either... I have do some
>>> ideas on possibly best course of action.
>>>
>>>
>>> -- snip --
>>> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
>>> and the SUFFIX property on a specific set of 25 targets amongst ~100
>>> targets. What am I to do ?
>>>
>>> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
>>> would be harder to set / unset on specific targets).
>>> * calling target_compile_options(...) 25 times ... well I mean, everyone
>>> knows it's bad to duplicate code. Especially if the change is meant to be
>>> only when a specific option() is enabled, or for debugging purposes
>>> * creating a function that would set the correct flags, etc and then call
>>> this function for each target is apparently "not modern CMake" either.
>>> * creating and linking to "dummy" INTERFACE targets with the flags and
>>> properties I want have an awful lot of limitations
>>>
>>> So what is the right course of actions here ?
>>> -- snip --
>>>
>>> I have started using add_library( targ INTERFACE ) to imperilment inherited
>&g
Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?
> Does that work for your needs?
Sadly, no (but thanks!). While this is enough for the arguably common use
case of include directories, compile flags, etc... there are plenty of
things that won't work with this approach.
e.g. none of this works for instance:
project(foo)
add_library(blah INTERFACE)
set_property(TARGET blah PROPERTY SUFFIX ".mxe")
set_property(TARGET blah PROPERTY CXX_STANDARD 14)
set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote:
> So there is some odd replies in the cmake mailing list possibly responses to
> wrong message, but this looked like a response to mine even if the initial
> reply to bit is not right from Nicholas. Anywho here goes:
>
> @Jean-Michaël Celerier
>
> -- snip --
> >* - Says that custom functions such as add_{project}_library shouldn't be
> *used and function definitions should be used as little as possible. Except
> this just leads to extremely verbose CMakeLists where repeated properties
> are defined again and again and again.
> -- snip --
>
> Yes add_project_library were my own and in the process of being deprecated.
> These were geared directly at two problems in cmake.
>
> 1) They were used to get CMake to support the concept of "inherited build
> properties".
>
> 2) As you stated and is still a problem the verbosity of CMake. Where IMO
> much could be collaped into one call
>
>
> -- snip --
> I also never understood how to handle this.
> -- snip --
>
> I am afraid I don't ultimately have the answer either... I have do some ideas
> on possibly best course of action.
>
>
> -- snip --
> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
> and the SUFFIX property on a specific set of 25 targets amongst ~100
> targets. What am I to do ?
>
> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
> would be harder to set / unset on specific targets).
> * calling target_compile_options(...) 25 times ... well I mean, everyone
> knows it's bad to duplicate code. Especially if the change is meant to be
> only when a specific option() is enabled, or for debugging purposes
> * creating a function that would set the correct flags, etc and then call
> this function for each target is apparently "not modern CMake" either.
> * creating and linking to "dummy" INTERFACE targets with the flags and
> properties I want have an awful lot of limitations
>
> So what is the right course of actions here ?
> -- snip --
>
> I have started using add_library( targ INTERFACE ) to imperilment inherited
> build properties. Yes the naming convention and use/reuse/misuse of
> add_library is horrid (library)
>
> I just posted this which may help:
>
> https://cmake.org/pipermail/cmake/2017-August/066119.html
>
> -- snip --
> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
> for $software", "target Bar is an integration test" and set per-group
> options, flags, properties, etc. Like
>
> add_group(PluginGroup)
> target_compile_definitions(PluginGroup -DBLAH)
> set_property(GROUP PluginGroup PROPERTIES /* whatever in
> cmake-properties*/)
> set_group(myTarget PluginGroup) // applies everything to the target
> -- snip --
>
> I won't have all the syntax for what your trying but possibly try:
>
> add_library( PluginGroupInterface INTERFACE)
> target_compile_definitions(PluginGroupInterface -DBLAH)
> set_property(GROUP PluginGroup PROPERTIES /* whatever in
> cmake-properties*/)
>
> I add interface, Interface, or _interface to my interface targets I use like
> this. Note here library in add library does not actually have to have a
> library (hence my statements to the horrid miss reuse of add_library for this
> functionality). It can just have build properties that you want a target to
> later inherit as far as I understand it or as far as I am miss using it if it
> is meant to be used some other way.
>
> then...
>
> add_executable( myTarget )
>
> target_link_libraries(
> myTarget
> PluginGroupInterface
> )
>
> Does that work for your needs?
>
>
>
> -- snip --
> Best,
>
> ---
> Jean-Michaël Celerier
>
> -- snip --
>
>
> --
>
> 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:
>
> C
Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?
> - Says that custom functions such as add_{project}_library shouldn't be
used and function definitions should be used as little as possible. Except
this just leads to extremely verbose CMakeLists where repeated properties
are defined again and again and again.
I also never understood how to handle this.
I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
and the SUFFIX property on a specific set of 25 targets amongst ~100
targets. What am I to do ?
* set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
would be harder to set / unset on specific targets).
* calling target_compile_options(...) 25 times ... well I mean, everyone
knows it's bad to duplicate code. Especially if the change is meant to be
only when a specific option() is enabled, or for debugging purposes
* creating a function that would set the correct flags, etc and then call
this function for each target is apparently "not modern CMake" either.
* creating and linking to "dummy" INTERFACE targets with the flags and
properties I want have an awful lot of limitations
So what is the right course of actions here ?
Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
for $software", "target Bar is an integration test" and set per-group
options, flags, properties, etc. Like
add_group(PluginGroup)
target_compile_definitions(PluginGroup -DBLAH)
set_property(GROUP PluginGroup PROPERTIES /* whatever in
cmake-properties*/)
set_group(myTarget PluginGroup) // applies everything to the target
Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Wed, Aug 23, 2017 at 1:30 PM, Uwe Koloska wrote:
> On 23.08.2017 11:44, Nicholas Devenish wrote:
> > - But simultaneously advocates rewriting internal functions using the
> > (undocumented?) '_' feature to access "previous definitions". Uses this
> > as one of the few examples of one of the steps as a method to allow a
> > script to change behaviour if being included.
>
> I have raised an issue on this undocumented behavior:
> https://gitlab.kitware.com/cmake/cmake/issues/17199
>
> Regards
> Uwe
>
> --
> Dipl.-Ing. Uwe Koloska
> Chief Software Evangelist
>
> voice INTER connect GmbH Tel +49 351 407 526 50
> Ammonstraße 35 Fax +49 351 407 526 55
> 01067 Dresden - Germanywww.voiceinterconnect.de
>
> Geschäftsführung: Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil
> Eingetragen im Handelsregister: Amtsgericht Dresden HRB 19466
>
> voiceINTERconnect www.voiceinterconnect.de
> ... smart speech applications from Germany
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam
That's a very useful feature to have! Ideally CMake would also try to load
it recursively up to the "/" folder just like for instance clang-format or
clang-tidy look for their configuration folders upwards. This would allow
for instance to easily build all the projects in a certain folder in
release mode by default or stuff like this.
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Wed, Aug 9, 2017 at 12:20 PM, Cristian Adam
wrote:
>
>
> On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis wrote:
>
>>
>> Is there a CMake equivalent to a site-config.jam or user-config.jam
>>
>> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html
>>
>> basically a CMake file the user can put in a project directory that CMake
>> will read first when using cmake-gui that allows user to specify stuff they
>> don't want to have to keep specifying in cmake-gui each "delete cache"
>>
>> such as
>>
>> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING ""
>> FORCE)
>> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE )
>>
>>
>> There is cmake.exe
>>
>> -C
>>
>> but requires command line
>>
>> come to think of it would be nice if
>> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" )
>>
>> in desired user config file and CMake would just "make it so" on clicking
>> Generate.
>>
>> I can do this with my own projects, by implementing it myself, but when
>> checking out 3rd party projs they can be all over the map on config
>> allowing a user-config.cmake would provide mechanism to tame the config
>> problems.
>>
>> Desired workflow
>>
>> 1) Checkout 3rd party proj
>>
>> 2) put a CMakeUser.txt or whatever file per project
>>
>> 3) Run CMake GUI Generate
>>
>> 4) Click Open Project
>>
>> 5) Change whatever manual bits in in gui
>>
>> 6) Update project suing git witch branches versions
>>
>> 7) Delete Cache
>>
>> 8) Return to 3
>>
>> 9) Doopy doopy doo whatever else
>>
>
> There is the (undocumented) PreLoad.cmake
> <https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmake.cxx#L1507>,
> which acts like giving a precache file with -C command line argument.
>
> But, as it turns out, it doesn't work with server mode :(
>
> Cheers,
> Cristian.
>
>
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
>
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Can't get CMake to link pthreads to my lib
I've tried this and also set(THREADS_PREFER_PTHREAD_FLAG TRUE) but this didn't work either. --- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Aug 8, 2017 at 4:01 PM, Rolf Eike Beer wrote: > Am 2017-08-08 15:45, schrieb Jean-Michaël Celerier: > >> Here's my CMakeLists.txt : >> >> >>>>>>>>> >> cmake_minimum_required(VERSION 3.8 FATAL_ERROR) >> project(oscour) >> set(CMAKE_INCLUDE_CURRENT_DIR ON) >> >> set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined") >> set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address >> -fsanitize=undefined") >> >> add_subdirectory(uWebSockets) >> > > set(CMAKE_THREAD_PREFER_PTHREAD On) > > find_package(Threads REQUIRED) >> > > Greetings, > > Eike > -- > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Can't get CMake to link pthreads to my lib
Here's my CMakeLists.txt :
>>>>>>>
cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(oscour)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined")
set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address
-fsanitize=undefined")
add_subdirectory(uWebSockets)
find_package(Threads REQUIRED)
add_library(oscour INTERFACE)
target_sources(oscour INTERFACE
${CMAKE_CURRENT_SOURCE_DIR}/oscour/oscour.hpp)
target_include_directories(oscour INTERFACE oscour/)
target_link_libraries(oscour INTERFACE uWS Threads::Threads)
target_compile_options(oscour INTERFACE -std=c++17)
add_executable(udp examples/udp.cpp)
target_link_libraries(udp PRIVATE oscour)
add_executable(tcp examples/tcp.cpp)
target_link_libraries(tcp PRIVATE oscour)
<<<<<<<<
As you can see, I call
find_package(Threads REQUIRED)
but at no point my example executables, named udp and tcp, link to -pthread
(or -lpthread) (which of course makes my build fails).
I also tried to link them explicitely to Threads::Threads. This did not
work either.
e.g. when doing make in verbose mode, the link invocation is :
/usr/bin/g++ -fconcepts -fsanitize=address -fsanitize=undefined -std=c++17
-fconcepts -fsanitize=address -fsanitize=undefined
CMakeFiles/complete.dir/examples/udp.cpp.o -o udp uWebSockets/libuWS.a
/usr/lib/libssl.so /usr/lib/libcrypto.so /usr/lib/libz.so
there is no hint of pthreads in there... what can I do ?
Best
Jean-Michaël Celerier
http://www.jcelerier.name
--
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:
http://public.kitware.com/mailman/listinfo/cmake
