[CMake] Imported targets with additional dependencies
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 via the target property IMPORTED_LOCATION. This used to work in 3.0.2, since it allowed me to specify multiple libraries separated by a semicolon (see here http://pastebin.com/Y1SYJFHh) but int 3.1-rc2 this semicolon is escaped to/replace by %3B. I was told that happens since there should only ever be a single entity specified by IMPORTED_LOCATION. So I got the suggestion to use LINK_INTERFACE_LIBRARIES instead. When linking against such a target via target_link_libraries(Bar Foo::Foo) without specifying the IMPORTED_LOCATION property, I get Foo::Foo-NOTFOUND in my linker dependencies. The thing is I cannot specify IMPORTED_LOCATION, since there is really none. I could use my first library dependency to fake one but that does not sound right. I also cannot define my imported library as an INTERFACE target because for these, LINK_INTERFACE_LIBRARIES is not supported. Is there any way to achieve the declaration of such a target in 3.1? Regards, Hauke -- 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] Imported targets with additional dependencies
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 hauke.hei...@gmail.com wrote: 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 via the target property IMPORTED_LOCATION. This used to work in 3.0.2, since it allowed me to specify multiple libraries separated by a semicolon (see here http://pastebin.com/Y1SYJFHh) but int 3.1-rc2 this semicolon is escaped to/replace by %3B. I was told that happens since there should only ever be a single entity specified by IMPORTED_LOCATION. So I got the suggestion to use LINK_INTERFACE_LIBRARIES instead. When linking against such a target via target_link_libraries(Bar Foo::Foo) without specifying the IMPORTED_LOCATION property, I get Foo::Foo-NOTFOUND in my linker dependencies. The thing is I cannot specify IMPORTED_LOCATION, since there is really none. I could use my first library dependency to fake one but that does not sound right. I also cannot define my imported library as an INTERFACE target because for these, LINK_INTERFACE_LIBRARIES is not supported. Is there any way to achieve the declaration of such a target in 3.1? Regards, Hauke -- 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] VS2010: /subsystem:console only in debug build
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 my example in all but release builds) I hope this helps. Regards, Hauke On Tue, Mar 6, 2012 at 11:55 AM, Andreas Haferburg ahaferb...@scopis.comwrote: Hi, I'd like to suppress the console, but only in release builds. What's the official way to do that? add_executable(... win32 ...) doesn't work, because it switches off the console in debug builds. When I set LINKER_FLAGS_RELEASE to /subsystem:windows, I can suppress the console in the release builds. However, the Properties window in VS2010 still displays Console (/SUBSYSTEM:CONSOLE) in the linker settings, and has two entries in the command line: /SUBSYSTEM:CONSOLE and /subsystem:windows. Only the latter seems to count. When I set LINKER_FLAGS_RELEASE to /SUBSYSTEM:WINDOWS, CMake just drops it, and only retains /SUBSYSTEM:CONSOLE in the linker flags. It seems to me that CMake recognizes /SUBSYSTEM:WINDOWS, but chooses to ignore it for some reason. The fact that /subsystem:windows works the way it does seems like a bug. So what's the proper way to achieve what I want? I'm using CMake 2.8.7 on Win 7 with VS2010. Cheers Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
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}
-P pathto/yourCopyDlls.cmake
VERBATIM
)
In the yourCopyDlls.cmake, you can GLOB your DLLs with or without
the d postfix depending on MSVC_BUILD_CONFIG_DIR. You can now even
copy additional files such as e.g. PDB files.
HTH,
Hauke
2012/1/9 Michael Stürmer m.stuer...@pmdtec.com:
I have found some topics related to my issue on the web, but none so far
helped me to fix it:
I use Visual Studio 2010 on Windows 7 64Bit.
During my build, all binaries are collected in one folder, which makes it
easier for me to debug the project. But to be able to run the program
actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
for the program to find them. Putting the libraries in the system path is
not an option for me, as I switch between 32- and 64-bit on the same system.
I managed to locate the folder where the dlls are (using some
CMake-Variables) and using a custom command like
ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
COMMAND copy “${DLL_3RD}/*.dll”
“${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIGURATION”
COMMENT “copying dlls …”
)
This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
that would be the relase as well as the debug libraries.
Now my question:
I would like to only copy those dlls I need, i.e. I have to determine
somehow if I’m in debug or release mode and select the appropriate libraries
by adding “d” for debug versions. For openCV I need “opencv_core231.dll” in
release and “opencv_core231d.dll” in debug mode. Does anyone have a
solution/workaround/idea for this problem?
Best regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
On Mon, Jan 9, 2012 at 4:11 PM, Michael Jackson
mike.jack...@bluequartz.net 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 could be auto generated based on what the programmer
says they need and then do the appropriate copy.
I experienced the exact same problem in the beginning - both libraries
had to be available. IIRC, passing ${CMAKE_CFG_INTDIR} to the script
allowed me to overcome this issue. The script does not even need to be
auto-generated. I am using one and the same script for all build
types.
- Hauke
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
2012/1/9 Michael Stürmer m.stuer...@pmdtec.com: 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 much convinced that you need a combination of your own script and GetPrerequisites since you want to copy to your run-time output directory - and there to specific sub-directories depending on the build type. It may well be that I have overseen some functionality in those new modules ... - Hauke -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Import/export issue with shared library
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 library B which is causing problems.
Scenario 1:
When A is an imported target defined in a ALibraryDepends.cmake
loaded by find_package(A), I can simply export B with
export(TARGETS B
FILE ${PROJECT_BINARY_DIR}/CMake/BLibraryDepends.cmake
)
Here, export(TARGETS B A ...) fails since A is just imported but not
build by the project.
Scenario 2:
When A and B are both part of the same project, the find script of A
does not load ${PROJECT_BINARY_DIR}/CMake/ALibraryDepends.cmake
since the target already exists in this project. But the export
statement from scenario 1) fails and I have to write
export(TARGETS B A
FILE ${PROJECT_BINARY_DIR}/CMake/BLibraryDepends.cmake
)
Here, export export(TARGETS B ...) fails because CMake needs to export
even the private shared library information. If I remember correctly,
there is something rpath specific behind this requirement.
Now I am wondering if there is any way to write my scripts such that
scenario 1) and scenario 2) are both working at the same time?
Any suggestions are appreciated.
Regards,
Hauke
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import/export issue with shared library
Hi Eric,
On Sun, Jan 8, 2012 at 5:20 PM, Eric Noulard eric.noul...@gmail.com 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, we build A once and leave it untouched and then
work on an isolated out-of-source build of B. SomeProject is usually
used only when everything is bundled into a single installer.
However from your last message it seems like you
export(TARGETS B A ...
statements depends on the fact that A (resp B.) is an imported target or not.
Exactly.
So may be you could add
get_target_property(IA IMPORTED A)
if (NOT IA)
set(EXPORTEDA A)
else()
set(EXPORTEDA )
endif()
export(TARGETS B ${EXPORTEDA} ...
Would this work for you use case?
This is interesting; I did not know about the IMPORTED property. I
could integrate this query into my hand-crafted export macro and I am
quite sure that it would help.
Thanks,
Hauke
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import/export issue with shared library
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()
before the actual export which fixes the problem.
Thanks again!
Hauke
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_directories, MSVC and $(Configuration)
On Tue, Dec 27, 2011 at 4:55 PM, Rolf Eike Beer e...@sf-mail.de 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. Consider e.g. boost; they link automatically on windows machines and they don't export their build targets. Typically I expect a library Foo which depends on boost to provide all required information to build after calling find_package(Foo) which in this case requires the definition of FOO_LIBRARY_DIRS containing the path to the boost libraries. But I see your point since I should enforce what you wrote for my personal libraries... Thank you for the tip! Regards, Hauke -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_directories, MSVC and $(Configuration)
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})
endforeach()
to override the behaviour.
Any hint is welcome.
Kind regards,
Hauke
--
CMake 2.8.5
Generator: Visual Studio 10 x64
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting IMPORTED_LOCATION_* for existing packages
Hi Michael, First, thank you for the feedback. On Thu, Sep 22, 2011 at 7:19 PM, Michael Hertling mhertl...@online.de 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 location of its *prerequisite* libraries reported by the GTest package's find module or config file. If I am not totally wrong, in this case I am only setting the GTest libraries and no additional *prerequisite*. The variable GTEST_LIBRARIES only contains full qualified paths to gtest.lib and gtestd.lib. IMO, this doesn't make any sense. Possibly, you want to set the GTest target's IMPORTED_LINK_INTERFACE_LIBRARIES[_CONFIG] properties in place of the IMPORTED_LOCATION[_CONFIG] ones. Maybe I am wrong, but I just tried to copy what is done in the FindQt4.cmake file or in other words to manually define what the export() directive generates. I recognized an issue since I forgot to define the property IMPORTED_CONFIGURATIONS. If I did not misunderstand things completely, you were right if GTEST_LIBRARIES would contain non GTest libs (the prerequisites). What do you actually intent to achieve? Introduce a GTest imported target and set up its prerequisites reported in GTEST_LIBRARIES as it would be done for imported targets from the first? I think that's pretty much what I want to do. Create the import target as if GTest were compiled with an export() directive. Doesn't the GTEST_LIBRARIES variable per se work for you? To be honest, in this case it does. Maybe the example was bad. I think I really need it for shared library targets, such as e.g. OpenCL. I want to prepare my libraries such that in the future a CMake based installation also collects and installs DLLs of interface libraries. I am further assuming that if I define a target of mine and link it against an imported (let's say) OpenCL target with properly specified IMPORTED_LOCATION (the DLL for shared libs), install() will copy it for me. Maybe that's long shot - I need to read more about the actual installation process and how it deals with dependencies. Regards, Hauke -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Setting IMPORTED_LOCATION_* for existing packages
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 REQUIRED)
add_library(GTest UNKNOWN IMPORTED)
foreach(arg ${GTEST_LIBRARIES})
if(${arg} MATCHES ^(debug|optimized)$)
set(_doing ${arg})
elseif(${_doing} MATCHES ^debug$)
message(setting debug lib to: ${arg})
set_target_properties(GTest PROPERTIES IMPORTED_LOCATION_DEBUG ${arg})
else()
message(setting optimized lib to: ${arg})
set_target_properties(GTest PROPERTIES IMPORTED_LOCATION ${arg})
endif()
endforeach()
I am just wondering whether there is a more simple method to do this.
It looks a bit cumbersome.
Regards,
Hauke
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Passing a CMake list as is to a custom target
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 expression. I did not look at the ExternalProject code but its working for me and I am now fine with the solution. Thanks again, - Hauke ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Passing a CMake list as is to a custom target
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, this list is always converted into a white-space
separated list for the target.
I tried to put ${ARGUMENTS} in quotes as well as escaped quotes but
the list is always converted.
My workaround is a foreach loop in which I am concatenating the
individual list elements via * and within Foo.cmake, I am reverting
this change through
string(REGEX REPLACE \* ; MY_VARIABLE ${MY_VARIABLE})
in order to get back to my actual list - but that seems hackish.
Any ideas how to prevent the conversion I mentioned above?
Regards,
Hauke
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Passing a CMake list as is to a custom target
On Wed, Jun 22, 2011 at 10:09 PM, Michael Hertling mhertl...@online.de 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_VARIABLE contains paths which may
contain white spaces, I explicitly chose the asterisk because it
cannot be part of a path.
Nonetheless thanks for the reply.
- Hauke
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake v.2.8.4 OpenSSL 1.0.0.d
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\cmcurl\CMakeLists.txt (ll. 183ff) FIND_LIBRARY(LIBEAY NAMES libeay32) and FIND_LIBRARY(SSLEAY NAMES ssleay32) failed. I fixed this by patching the CMakeLists.txt and adding the appropriate PATHS statements for my system. I know, its a little bit invasive but for the moment I did not care. I am wondering why you do not use the results from find_package(OpenSSL). There you already search for those libs and they were found on my system. Anyways, I finally managed to create the project files to the MSVC2010, x64 generator. Now, when I try to build, I am facing a bunch of compilation errors. Some symbols cmcurl needs seem to have changed. E.g. SSL_CTX seems to be undefined. Could it be, that I am using a wrong OpenSSL version? Did you ever test to build CMake against OpenSSL in x64 bit mode? Any hints would be welcome since I would love to stick to my CDash behind https. Regards, Hauke ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Testing and DLLs
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_DIRECTORY but that did not affect my tests (added via add_test). Another solution I can think of is running make INSTALL before running the tests but that feels like a strange approach since I typically want to test before installing. Its also not really possible to adapt the PATH environment variable - how could I possible guess where somebody is going to build my code!? So again, I am really curious if there is a well working solution. Regards, Hauke ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing and DLLs
I forgot to reply to all.
The gist is that I did override the output directories in some
sub-modules. I.e. setting CMAKE_*_OUTPUT_DIRECTORY is really all I
need.
- Hauke
On Wed, May 4, 2011 at 6:26 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Are you talking about the actual library/DLL that you are creating or some
3rd party library that your built library depends on? If you do this:
# -- Setup output Directories -
SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all Libraries
)
# - Setup the Executable output Directory -
SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all Executables.
)
# - Setup the Executable output Directory -
SET (CMAKE_ARCHIVE_OUTPUT_DIRECTORY
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all static libraries.
)
All the libraries and executables should be built into the same location?
___
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 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_DIRECTORY but that did not affect my tests (added via
add_test).
Another solution I can think of is running make INSTALL before
running the tests but that feels like a strange approach since I
typically want to test before installing.
Its also not really possible to adapt the PATH environment variable -
how could I possible guess where somebody is going to build my code!?
So again, I am really curious if there is a well working solution.
Regards,
Hauke
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to write find_package when *Config.cmake is given?
Hi,
I am wondering how to write find_package when I am providing a
moduleConfig.cmake file.
Do I do something like this?
find_file(MY_CONFIG_FILE moduleConfig.cmake HINTS ...)
if (MY_CONFIG_FILE)
include(${MY_CONFIG_FILE})
endif()
What I actually would like to have is a configuration like this
/foo/moduleA
/foo/moduleB
/foo/superProject
in which moduleB depends on moduleA and in which I can build each
module individually but also all together in a superProject.
With the setup above, building each of the libraries on its own, works
just fine -- as long as the order is correct.
As soon as I switch to the superProject setting, the configuration
is not the way I would like to have it. moduleB still links against
the installed version of moduleA (my find_package points to this one)
whereas I would like moduleB to link against the version of mdouleA
which is being build by the superProject.
Is there a simple CMake trick to achieve this behavior? Any help is
highly appreciated!
Regards,
Hauke
---
Main references I've read till now ...
[1] http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file
[2] http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries
[3] \CMake 2.8\share\cmake-2.8\Modules\readme.txt
[4] ITK modularization configuration files ...
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Three short questions...
Hi again,
first of all, thanks for the quick answer.
Actually all of the requests were merely taste related. I admit that
this is not really important but from time to time I am looking at the
libraries and includes I am using and then I like it, if they are
nicely formatted or as short as possible.
Philip Lowman wrote:
Hi
there,
I've stumbled over three little questions which I could not answer from
the FAQs nor the CMake documentation or the Wiki. Maybe one of the
specialists can help me out...
The first question is whether it is possible to prevent environment
variables from being expanded by CMake when it comes to setting include
or link directories (INCLUDE_DIRECTORIES and LINK_DIRECTORIES).
Not sure what you mean here. You might be able to do this (don't know,
never tried), but I wouldn't recommend it:
INCLUDE_DIRECTORIES($ENV{FOO})
Actually colleagues and me are oftentimes using environment variables.
Until now we used to work solely with Visual Studio Project files being
distributed along different machines and it turned out to be very
convenient to have a base directory of your third party libraries and
your core library defined in environment variables. Nobody needed to
change any configuration files and thus we could put them to the SVN.
With CMake it is working fine as well though I usually use
FILE(TO_CMAKE_PATH $ENV{FOO} CMAKE_FOO).
The
second question is whether I can prevent the MSVC generator to append
$(OutDir) to LINK_DIRECTORIES. For each call to LINK_DIRECTORIES I get
two directories (e.g. LINK_DIRECTORIES(c:/foo/bar) creates
c:/foo/bar/$(OutDir) and c:/foo/bar).
I didn't even realize that it did that. I think that's probably meant
as a convenience for MSVC developers who sometimes like to share the
same filename across different release configurations (in different
directories obviously). Not sure if it's disableable or not, is it
causing you problems?
Does not cause any problems, but since we usually differentiate via
postfix and not via directory we just don't need it. Again... it's just
taste.
And
the last question is, if it is possible to tell the FindQt.cmake script
to give me the plain libraries without the full path of them being
prepended (I am talking about the content of the QT_LIBRARIES
variable). I would rather like to use LINK_DIRECTORIES and
TARGET_LINK_LIBRARIES separately, i.e. I would prefer QtGuid4.lib over
C:\Qt\lib\QtGuid4.lib.
It should be possible to do this with STRING(REGEX REPLACE... ) if
there is no better way. I'm curious why you would need to do this
though. The use of TARGET_LINK_LIBRARIES() with full paths is highly
desired over LINK_LIBRARIES() and TARGET_LINK_LIBRARIES() with a
relative library filename.
Ok, I see what you mean though I am wondering why in general not all
CMake Find modules follow this paradigm. For instance all of my ITK
libraries seem to be 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 CONFIGURATIONS option.
Cheers,
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake
Ok, now that we have collected a list of problems/facts, I have the feeling that we need to step back and make a wishlist... There is no way in writing an all-purpose version scripts since there exist contradictory paradigms. I will start by the list of problems/facts: * BLAS and CBLAS do have different interfaces * LAPACK and CLAPACK do have different interfaces * Fortran underscoring issues What I do not regard as a problem: * Missing interface headers / proxies (up to the developer) * Memory layout (row vs. column major, actually it's part of the interface) * The case when a C/C++ developer wants to use a Fotran compiled library. It is sometimes required (e.g. for CBLAS) and the devloper better has some good unit tests at hand to do the final error checking... And now to my wishlist: 1) FindBLAS.cmake: -- a) Should work without a Fortran compiler (CBLAS requires BLAS) b) Support for f2c'ed versions (afaik, requires additional dependencies) c) Optimized alternatives should get higher priority in the search than non-optimized ones d) Should figure out and store the used underscoring convention (I am absolutely not sure about this one...) 2) FindCBLAS.cmake: --- a) Well, we need it (I already told Alan, that I am willing to write it) b) Should be able to use FindBLAS.cmake (Legacy BLAS is required by CBLAS), even without a Fotran compiler being present... 2) FindCBLAS.cmake: --- Things I assume to be true from the script's point of view * A sane system, i.e. not 10 different versions of BLAS Co. The script will simply return the first one it stumbles upon * BLAS and commercial alternatives may though coexist. The script might return at first optimized versions and then non-optimized ones. Actually, the Fortran underscoring remains an issue, since there exist two possible solutions (that is also the main reason, why we cannot have a general purpose script). a) We try to figure out the underscoring convention from within the script since some libraries that require BLAS offer the possibility to set the used convention via pre-processor defines. b) We let the developer tell the script the desired convention via a variable. In my opinion the latter solution is as valid as the first one since the developer is actually writing the CMake script, so he should know which convention he wants to have. From a CMake-script implementation point of view the latter solution is simmpler to implement but requires the user to pass a parameter to FindBLAS.cmake. This first method has the advantage that in case of a library supporting dynamic underscoring convention 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 Hauke Heibel Computer Aided Medical Procedures (CAMP) fon: +49 89 289 19427 fax: +49 89 289 17059 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Extension proposal: CheckFortranFuinctionExists.cmake
Hi there,
I started diving into the world of CMake and spend the last two days in
trying to convert a project of mine to be working with CMake.
We are using BLAS in the project, so obviously I gave FIND_PACKAGE(BLAS)
a shot. In the beginning it was not really working, but I found a
workaround which I would like to discuss - maybe it will be useful for
others as well.
So here is the scenario. I am given a machine having only access to
static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib
and f77blas.lib). It would be great if the FIND_PACKAGE script would
allow me to use these libraries even when I do not have a Fortran
compiler at hand. Why should I need it anyways - the libs are pre-compiled.
So in the first step I managed to get FindBLAS.cmake running that far,
that it finds the libs but as said before, it was failing due to the
missing Fortran compiler. To resolve this final issue I did the following.
Since Fortran compiled libraries can be used from C/C++, why not simply
create a test based on a .cpp file. I gave it a try and it seems to work:
CheckFortranFunctionExists.cmake (I cut things short here)
IF(_LANGUAGES_ MATCHES Fortran)
#
ELSE(_LANGUAGES_ MATCHES Fortran)
FILE(WRITE
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testFortranCompiler.cpp
extern \C\ void ${FUNCTION}();
int main(int argc, char* argv[])
{
${FUNCTION}(); // force linking
return 0;
}
)
try_compile(${VARIABLE}
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testFortranCompiler.cpp
CMAKE_FLAGS ${CHECK_FUNCTION_EXISTS_ADD_LIBRARIES}
OUTPUT_VARIABLE OUTPUT
)
ENDIF(_LANGUAGES_ MATCHES Fortran)
Unless I did not get something seriously 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 289 19427
fax: +49 89 289 17059
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake
Bernd Schubert wrote: On Wednesday 25 June 2008, Alan W. Irwin wrote: I think that assumption needs lots of qualifiers. Did your run-time actually give correct numerical results when linking from a C main programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky business. There is a project called cfortran that tries to do it for all the different Unix variants, but it is pretty complicated because of various naming conventions on each brand of Unix. Because of those complications, systems often have both C and Fortran versions of BLAS installed. For example, it appears your system has cblas.lib which is the library I think you want to link to from C/C++ code. No, it is really no problem to link fortran libraries and to call their functions. It is onkly a bit nasty sometimes to write the proto types of the blas/lapack functions, since nobody seems to have created a complete set of these, afaik. For real number crunching one also uses the intel/amd or goto libraries and there is always only one library of these, for both C and Fortran (afaik, these optimized libraries are also not written in fortran anymore, they just have this stupid interface to be compatible with fortran. The other issue with fortran libraries is to figure out, how these have been compiled (additional underscores, etc). On the other hand, cblas even has a slightly different interface than nativ blas, so without changing the existing code it is not suitable for linking. From my experience a huge problem is the way in which the libs are compiled (this refers to the underscore issue mentioned by Bernd). This is currently not taken care of at all. In Boost's numeric bindings this is taken care of by a special macro called FORTRAN_ID. It is not straight forward to find out how the code has been compiled, but it could be done by trial and error. If e.g. the linking in my example from the previous mail fails it may be due to two reasons, either the libs are missing or they have been compiled including a leading underscore. Well, maybe even more flavors exist. Regarding the compatibility, I tried out and verified quite a few of the functions offered via CBLAS and LAPACK mainly via http://boost-sandbox.cvs.sourceforge.net/boost-sandbox/boost-sandbox/boost/numeric/bindings/ . Unfortunately I did not build the libraries I am currently working with myself so I can not give detailed information about how they were built but my unit tests yielded correct results. >From another Fortran library (Dierckx Fitpack) which I built myself from within the Cygwin environment (g77 -fno-underscoring -mno-cygwin -O3 -c *.f followed by lib *.o /out:fitpack.lib), I can say that, at least in the way I build the libs, it is absolutely possible to use the functions and get correct results. Obviously this requires some work by the user, again because of the missing proxies. Row vs. column major storage is from what I know also something one has to take care of. Regarding the last comment of Bernd, regarding different interfaces of CBLAS and native BLAS, I have no clue - but if that is true, isn't it then dangerous to check at first for the "cblas;f77blas;atlas" (FindBLAS.cmake lines 88-97) libraries and then for "sgemm;dgemm;blas" (FindBLAS.cmake lines 100-107), etc. ?? Finally I want to emphasize that the effort that has been done in creating the FindBLAS package is highly appreciated and that I am not at all a Fortran specialist. I just have little experience with mixing Fortran and C/C++ and so far I seem to have 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://www.cmake.org/mailman/listinfo/cmake
