Re: [CMake] Using generator expression with add_library

Another option is to use BUILD_SHARED_LIBS to control static vs. shared. Set it to false on MSVC and true everywhere else, then omit the library type in the add_library calls that you wish to have controllable behaviour. Those add_library calls will then consult BUILD_SHARED_LIBS to determine

Re: [CMake] cross-testing support in cmake

Does https://cmake.org/cmake/help/latest/prop_tgt/CROSSCOMPILING_EMULATOR.html#prop_tgt:CROSSCOMPILING_EMULATOR do what you're looking for? From: CMake on behalf of Stefan Seefeld Sent: November 5, 2019 6:06 PM To: CMake Subject: [CMake] cross-testing support

Re: [CMake] CMake Release Candidate Builds Available for Ubuntu

Thanks for the RCs, Kyle (and the rest of the CMake crew). I tried 3.15~rc1 and it seems to have been built without https support file(DOWNLOAD https://foo/bar) gives a status "1;Unsupported protocol". This is with version 3.15.0~rc1-0kitware2 amd64 running on Bionic. Version 3.14.5-0kitware1u

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

ot;$<$:bar>" ) A little more verbose. From: Björn Blissing Sent: October 4, 2018 9:00:28 AM To: Andrew Fuller; Eric Noulard Cc: CMake Mailinglist Subject: RE: [CMake] Trouble with conditional generator expression inside target_link_libraries Hi Andrew, When I put the genex ins

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

What happens if you put the genex inside double quotes? target_link_libraries(my_exe PUBLIC "$<$:${FOO_LIBRARIES}>" "$<$:bar>" ) From: CMake on behalf of Björn Blissing Sent: October 4, 2018 8:49:19 AM To: Eric Noulard Cc: CMake Mailingl

Re: [CMake] Parallel builds and auto generated header files

Using configure_file() at CMake time will appear to work at first glance, but you'll wind up with stale information when you change revisions without any CMake change. CMake won't re-run automatically and thus your header file won't get updated. You'll need to do it at build time to ensure it'

Re: [CMake] Generating include files

> Hm, it's the same info I've already found in other places. > Unfortunately, I still don't see a way to generate a source file that > should be #include'd instead of linked into an executable. I missed that you wanted a .h file that other libraries would pick up. Since CMake isn't aware of whi

Re: [CMake] Generating include files

> Is there a way to specify that foo.o depends on tab.c? For some > reason cmake's scan does not seem to find this. Does the following work for you? The first bit is just putting some fixed files for convenience. The second bit is the interesting bit. In your build directory you won't have

Re: [CMake] Trouble with FindPNG module

Try adding this to your toolchain file: set( CMAKE_C_LIBRARY_ARCHITECTURE "i386-linux-gnu" ) set( CMAKE_CXX_LIBRARY_ARCHITECTURE "i386-linux-gnu" ) From: rcdai...@gmail.com on behalf of Robert Dailey Sent: April 24, 2017 10:22:53 AM

Re: [CMake] Trouble with FindPNG module

Where did the library get installed on your system? What's the value of CMAKE__LIBRARY_ARCHITECTURE? Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit libraries unless you've told it otherwise. From: CMake on behalf of Robert Dailey

[CMake] Clarifying PUBLIC_HEADER property and non-FRAMEWORK / STATIC / INTERFACE libraries

I'm finding the PUBLIC_HEADER target property to be quite convenient for clarity's sake. Specifically it spells out quite unambiguously that "hey, these are the headers I want to be published" while at the same time providing locality to the export details with "PUBLIC_HEADER DESTINATION foo" a

Re: [CMake] generator expressions

On Fri, Jun 6, 2014 at 8:43 AM, Brad King wrote: > On 06/06/2014 11:37 AM, Andrew Fuller wrote: > > Should I be quoting all my generator expressions? > > Is that the proper syntax? > > The CMake language does not actually know anything about generator > expressions. Th

Re: [CMake] generator expressions

On Fri, Jun 6, 2014 at 8:28 AM, Brad King wrote: > On 06/06/2014 11:07 AM, Andrew Fuller wrote: > > On Fri, Jun 6, 2014 at 6:08 AM, Brad King <mailto:brad.k...@kitware.com>> wrote: > > > > I cannot reproduce these. Can you provide a complete CMakeLi

Re: [CMake] --graphviz and generator expressions

Sorry, I meant to keep this on the mailing list. Hit reply without checking. On Thu, Jun 5, 2014 at 1:33 PM, Andrew Fuller wrote: > A non-trivial overhaul of the graphviz option implementation will >> be needed to make it useful on projects using modern features. >> > &g

Re: [CMake] --graphviz and generator expressions

wo' but not on 'one'. Am I doing something wrong, or should I file a bug? On Thu, Jun 5, 2014 at 9:41 AM, Andrew Fuller wrote: > I'm trying out the --graphviz option to visualize link dependencies -- > very useful! > > It seems to me that it does not understa

[CMake] --graphviz and generator expressions

I'm trying out the --graphviz option to visualize link dependencies -- very useful! It seems to me that it does not understand generator expressions. We make use of generator expressions to bring in platform-specific libraries and when I generate the graphviz on Linux I'm still seeing Windows lib

Re: [CMake] target_include_directories and relative paths inside generator expressions.

On Thu, Apr 24, 2014 at 1:21 AM, Stephen Kelly wrote: > Andrew Fuller wrote: > > > It seems absolute paths are necessary. eg: > > > > target_include_directories( MyTarget PRIVATE > > $<$:${CMAKE_CURRENT_SOURCE_DIR}/some/dir> ) > > > > will perform

[CMake] target_include_directories and relative paths inside generator expressions.

Running CMake 3.0-rc3 and the docs for target_include_directories say the paths may be absolute or relative. Indeed the following works as desired: target_include_directories( MyTarget PRIVATE some/dir ) The docs also mention that generator expressions can be used. However the following produce