I just received help on IRC.
The solution is to use an INTERFACE target and INTERFACE_LINK_LIBRARIES
(and NOT LINK_INTERFACE_LIBRARIES).
Hauke
On Wed Nov 19 2014 at 2:26:54 PM Hauke Heibel
wrote:
> Hi,
>
> I would like to declare an imported target which uses a header only
> libra
Hi,
I would like to declare an imported target which uses a header only library
and which has some further link dependencies. If need be, I can specify a
use case for this.
I thought I could simply declare this target as
add_library(Foo::Foo UNKNOWN IMPORTED)
and then configure its dependencies
Hi Andreas,
as far as I know, your only chance to achieve this is by modifying your
source code by adding
#ifndef NDEBUG
#pragma comment(linker, "/SUBSYSTEM:CONSOLE")
#endif
Using add_executable(... win32 ...) is correct because the pragma statement
will override the behaviour in debug mode (in
2012/1/9 Michael Stürmer :
> Awesome! Sometimes you just need to know what's already available to solve
> your problems in a very elegant way. I'll have a look at these bundles and
> probably switch to them instead of maintaining my own stuff!
When looking at the initial problem, I am pretty muc
On Mon, Jan 9, 2012 at 4:11 PM, Michael Jackson
wrote:
> The only issue I really have with this is that this macro requires there to
> be BOTH debug and Release libraries available and will copy BOTH no matter
> which configuration is being built. I am thinking that the
> "yourCopyDlls.cmake" c
Hi Michael,
What I do is running a custom command which itself executes a CMake
script. Usually similar to
add_custom_command(TARGET CopyDlls
COMMAND ${CMAKE_COMMAND}
-DMSVC_BUILD_CONFIG_DIR=${CMAKE_CFG_INTDIR}
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
Perfect, what you suggested works like a charm. Within a small macro I
am now running this code
set(EXPORT_TARGET_LIST ${ARGV})
foreach(TARGET_UID ${ARGV})
get_target_property(IA ${TARGET_UID} "IMPORTED")
if(IA)
list(REMOVE_ITEM EXPORT_TARGET_LIST ${TARGET_UID})
endif()
endforeach()
bef
Hi Eric,
On Sun, Jan 8, 2012 at 5:20 PM, Eric Noulard wrote:
> I'm not sure how you compile your example.
> Should they be built in-source?
> Do you create out-of-source build tree for each A,B,SomeProject?
I usually build out-of-source. What is built out-of-source is up to
the user. Typically,
Hi,
I have the following problem and any help would be appreciated.
I have a shared library B which links to another shared library A
(with the new LINK_PRIVATE flag specified and the linking is carried
out against A's target). In B's CMake file, there is an export
statement for the shared librar
On Tue, Dec 27, 2011 at 4:55 PM, Rolf Eike Beer wrote:
> Don't use link_directories. Ever. You don't want to use it. Surely. It does
> not what you think it does. It only exists to create trouble, unexpected
> behaviour and questions to this list ;)
If that were possible it would be great. Consid
Hi all,
I am wondering whether it is intended that the link_directories is
appending the $(Configuration) sub-directory only to the last
directory when a list of directories is passed to it?
I had to write something like
foreach(link_dir ${LIBRARY_DIRS})
link_directories("${link_dir}")
e
Hi Michael,
First, thank you for the feedback.
On Thu, Sep 22, 2011 at 7:19 PM, Michael Hertling wrote:
> AFAICS, you've a single imported target GTest, and you are continuously
> setting *this* target's location - sometimes for a debug configuration,
> sometimes without configuration - to the l
Hi,
I started to work with imported targets and thus with setting the
property IMPORTED_LOCATION and the like. I stumbled over a case
(GTest) where the standard find_package call returns me a list of libs
for 'debug' and 'optimized' modes and I am setting them like this
find_package(GTest REQUIRE
Thank you for the feedback. I adopted using "::" as a separator and I
added en- and decode functions to my macro library. It's probably the
cleanest solution.
The only remaining comment is that opposed to the example David
posted, I get wrong results when escaping the semi-colon in the
regular exp
On Wed, Jun 22, 2011 at 10:09 PM, Michael Hertling wrote:
> You might use -DMY_VARIABLE="${ARGUMENTS}" without VERBATIM, and
> SEPARATE_ARGUMENTS(MY_VARIABLE) in Foo.cmake. This doesn't prevent
> the list's conversion, but seems a bit smarter than a FOREACH loop.
I considered this but since MY_VA
Hi,
My CMake version is 2.8.3 and I am trying to run a CMake script as a
custom target via
add_custom_target(RunFooTarget ALL
COMMAND ${CMAKE_COMMAND}
-DMY_VARIABLE=${ARGUMENTS}
-P Foo.cmake
VERBATIM
)
where ${ARGUMENTS} is a standard CMake list (semi-colon separated).
Unfortunately,
Hi,
I just tried to build CMake 2.8.4 on Win7 (MSVC 2010, x64) against
OpenSSL 1.0.0.d.
I built OpenSSL by hand and started the cmake-gui with the
-DOPENSSL_ROOT_DIR set to the build directory and with an
appropriately configured CMAKE_INCLUDE_PATH.
First, CMake failed because in Utilities\cmcur
___
> Mike Jackson www.bluequartz.net
> Principal Software Engineer mike.jack...@bluequartz.net
> BlueQuartz Software Dayton, Ohio
>
> On May 4, 2011, at 11:46 AM, Hauke Heibel wrote:
>
>> Hi,
>>
>> I am
Hi,
I am curious whether there is a common way of dealing with unit tests
when the actual project to be tested is a DLL? The issue I am facing
is a common Windows issue where the required DLL is not found in the
path.
I tried to put all binaries in the same directory by modifying
CMAKE_*_OUTPUT_D
Hi,
I am wondering how to write find_package when I am providing a
Config.cmake file.
Do I do something like this?
find_file(MY_CONFIG_FILE "Config.cmake" HINTS "...")
if (MY_CONFIG_FILE)
include(${MY_CONFIG_FILE})
endif()
What I actually would like to have is a configuration like this
/foo/
e set via TARGET_LINK_LIBRARIES() without the path
and the path (here luckily including the $(OutDir), which I just
realized) seems to be set via LINK_DIRECTORIES(). Maybe it is done that
way to support the multi-target MSVC generator because
LINK_DIRECTORIES() does not (yet?) support the CONFIG
o use LINK_DIRECTORIES and
TARGET_LINK_LIBRARIES separately, i.e. I would prefer QtGuid4.lib over
C:\Qt\lib\QtGuid4.lib.
I am using CMake 2.6-patch 0. Any hints would be great.
Regards,
Hauke
--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 289 19427
fax: +49 89 289
n configuration via pre-processor defines,
people could use one and the same library with one or the other convention.
Before starting we need to be sure that we know exactly what we want,
especially regarding the underscoring issue.
So let's go for the next round... :)
- Hauke
--
Tim Hau
ave been lucky. There may be
(and unfortunately probably are) some issues I am not aware of.
- Hauke
--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 289 19427
fax: +49 89 289 17059
___
CMake mailing list
CMake@cmake.org
http
wrong with the idea of testing,
the proposed method should work. If anybody is interested, I could
create a CVS patch and submit it as a feature request to Mantis.
Regards,
Hauke
--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 2
25 matches
Mail list logo
