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

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

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

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

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

.li...@gmail.com> Sent: April 24, 2017 10:22:53 AM To: Andrew Fuller Cc: CMake Subject: Re: [CMake] Trouble with FindPNG module The output is: x86_64-linux-gnu How can I tell CMake to look for 32-bit libraries? I would like to force this from my toolchain file (which I posted a few minutes ago

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

[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"

[cmake-developers] Improved handling of %directives in CPACK_RPM_USER_FILELIST

-patch to this list is desired. Cheers, -Andrew?? From 13717c3943e11848233f6c8e95ee69ba3bda3ec1 Mon Sep 17 00:00:00 2001 From: Andrew Fuller <aful...@teradici.com> Date: Fri, 24 Jun 2016 10:45:40 -0700 Subject: [PATCH] Adjust the regex to handle %foo and %foo(anything) directives. Dire

Re: [CMake] generator expressions

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

Re: [CMake] generator expressions

On Fri, Jun 6, 2014 at 8:43 AM, Brad King brad.k...@kitware.com 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. They are just

[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

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 mactalla.ob...@gmail.com wrote: A non-trivial overhaul of the graphviz option implementation will be needed to make it useful on projects using modern features. Okay

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

On Thu, Apr 24, 2014 at 1:21 AM, Stephen Kelly steve...@gmail.com wrote: Andrew Fuller wrote: It seems absolute paths are necessary. eg: target_include_directories( MyTarget PRIVATE $$PLATFORM_ID:Linux:${CMAKE_CURRENT_SOURCE_DIR}/some/dir ) will perform as expected

[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