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
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
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
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
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
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
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"
.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
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
> 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
> 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
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
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
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
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
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
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
-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
18 matches
Mail list logo