Re: [CMake] Code Coverage & Bullseye
Thou shall receive the patch :) On Thu, Sep 18, 2014 at 5:56 PM, David Cole wrote: > My apologies. I take it back -- gcov apparently does work on the Mac > nowadays. > > It is a ctest issue, then, and when using Xcode, ctest will need to look > in some additional locations for the coverage data files. > > The source code is available -- patches welcome. :-) > > > D > > -- 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] Get Visual Studio target Arch
Hi Alexey I’ve updated our installers to get installed in CMakeMS instead of CMake, this allows you to run both side by side. If you want to rename the executable to be CMakeMS.exe, you can, I just felt that for people relying on scripts, this could be a hard change to take. ~Gilles -- 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
[CMake] Exporting a library shared and static
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I have a project that consists of a library and an application that are developed as two separated projects (different repos, separate cmake setups, etc.). Let's call them "lib" and "app". The app exports itself to ~/.cmake/ and creates a appTargets.cmake, the app simply does find_package(lib). For several reasons, we must be able to build the app dynamically and statically. Our current approach is based on a flag "STATICLIB_SWITCH" that exists in the lib and in the app. Based on it's value, we build the library as .a or .so and link the app statically or dynamically. However, there are a few drawbacks: The value of the switch has to be consistent for the lib and the app and we didn't quite manage to correctly search for all libs: The linker command line is cluttered with lots of -rdynamic etc, which also occasionally breaks down and is very hard to debug when it does. So I spent some time on this and it seems that this is meant to be done differently. My new setup looks like this: The lib has two targets, for a shared object and for a static object, that are always built and exported. The app includes whatever it needs. This would remove the switch from the lib, which would be very nice. However, it seems that the app always includes the "shared target", no matter what I do. Also, I have not been able to provide the target with the list of libraries necessary: I simply collect all libraries in a variable that are found by other find_package calls, but find_package will only find either the shared or the static versions... So basically my question is: How is this supposed to be done? (I somehow get the feeling, that both attempts are wrong :-) ) How can I use a library in another application and switch (fairly) easily between static and dynamic linking? Thanks for any hints on this! Gereon PS: I accidently posted this mail on cmake-developers a few days ago and realized today, that I got the wrong list. Sorry for that! -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUGv/GAAoJEIQ2nMX673Hfg+IIAKOZ9rpbAk4LKsgwwEmTdjLq Zy2LnsFcZqc/oRjaPVxLdJyWYDgtD4fi5SE3YGLn9VaHP9UM/KOWZGMGRew5358U yf8X1RTAW+0bH+RWqjjqry3FUl6YY+vlkAPvmEO2cnFgXLI3WONB5TZLm0M/EJR3 iDG3Dgk55BPlwOnEV06rMWauYr2iwK7HQv2lOBGKfoMFLb8lIYZKHROOBuvjE3gJ xbosZ7tZ+t62Db9BcxKsT716dgA6KWuZLnrLsuKChBA+RXPYlUph90IZN5pBg+L6 MU+bPePGtW3SWpY4XsEU8a9+7QQekCgT948NQUOTWK38kBPnJzSsmPLIybHQTik= =teCh -END PGP SIGNATURE- -- 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] CMAKE_CFG_INTDIR
- Original Message -
> On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> > Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> > in configure time, instead of build time?
> >
> > If there is not, is it safe to assume that the name of the directory is
> > equal to the name of the current configuration?
>
>
> Bump?
>
> What I would like to do is to be able to change
> CMAKE_RUNTIME_OUTPUT_DIRECTORY (and similar variables) with something
> that contains the current configuration directory, i.e.
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY .../${CMAKE_CFG_INTDIR}/...)
>
> but unfortunately CMAKE_CFG_INTDIR causes an error when targets are
> installed.
As expected, that will not work. CMAKE_CFG_INTDIR can give the build tool a
variable, which is expanded by the build tool, and you've effectively added
another configuration directory level.
You could end up with a directory such as
/path/to/Debug/Debug/
>
> I was able to have something that works as I expect by doing this:
>
> foreach(config ${CMAKE_CONFIGURATION_TYPES})
> string(TOUPPER ${config} CONFIG)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONFIG} .../${config}/...)
> endforeach()
>
> But I was wondering if it is safe to assume that the current directory
> is always "${config}" or if it might be different.
>
That should work just fine. CMAKE_CONFIGURATION_TYPES gives you a list of all
possible configuration that can be chosen at build time.
Clint
--
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] [Cdash] Show results from the bullseye coverage in CDash
When i start "ctest -V -V -S CTestScript.cmake" manually on the command line, I see the following messages: Performing coverage RegularExpression::compile(): ?+* follows nothing. RegularExpression::compile(): Error in compile. Best regards > Am 17.09.2014 um 13:07 schrieb Rolf Eike Beer : > > Am 17.09.2014 12:02, schrieb David Cole via CMake: >>> No, the submit seems fine, but the value in the Coverage.xml looks >>> like >>> 0.00 >>> 0.00 >>> Which can't be. >>> However, the *-covbr.* and *-covsrc.* are generated with valid values. >> Sounds like a bug in ctest then. There must be something going wrong in >> the code that reads the coverage files and generates Coverage.xml. >> Can you reproduce the problem with a minimal test case? Or debug it >> yourself to analyze what's going wrong with ctest on the machine >> demonstrating the problem? > > Excellent would be if you could provide an output file of Bullseye that shows > that problem that could later be used in an automated test, the code parsing > Bullseye data is currently not tested at all. Ideally you would use Bullseye > to analyze either a dummy file or something from CMake itself so you do not > need to show anything of your code (and CMake doesn't need to ship that). > > Greetings, > > Eike > -- > > 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 -- 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] CMAKE_CFG_INTDIR
On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> in configure time, instead of build time?
>
> If there is not, is it safe to assume that the name of the directory is
> equal to the name of the current configuration?
Bump?
What I would like to do is to be able to change
CMAKE_RUNTIME_OUTPUT_DIRECTORY (and similar variables) with something
that contains the current configuration directory, i.e.
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY .../${CMAKE_CFG_INTDIR}/...)
but unfortunately CMAKE_CFG_INTDIR causes an error when targets are
installed.
I was able to have something that works as I expect by doing this:
foreach(config ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER ${config} CONFIG)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONFIG} .../${config}/...)
endforeach()
But I was wondering if it is safe to assume that the current directory
is always "${config}" or if it might be different.
Cheers,
Daniele
--
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] Code Coverage & Bullseye
My apologies. I take it back -- gcov apparently does work on the Mac nowadays. It is a ctest issue, then, and when using Xcode, ctest will need to look in some additional locations for the coverage data files. The source code is available -- patches welcome. :-) D -- 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] Code Coverage & Bullseye
As David suggested I did following experiment. I created two Test projects. *Project1: * *set(CTEST_SOURCE_DIRECTORY /Users/rajekumar/work/test-codes/TestUnix)* *set(CTEST_BINARY_DIRECTORY /Users/rajekumar/work/test-codes/TestUnix/out)* *set(CTEST_CMAKE_GENERATOR "Unix Makefiles")* *set(CTEST_BUILD_COMMAND "make")* *Project2:* *set(CTEST_SOURCE_DIRECTORY /Users/rajekumar/work/test-codes/TestMac)* *set(CTEST_BINARY_DIRECTORY /Users/rajekumar/work/test-codes/TestMac/out)* *set(CTEST_CMAKE_GENERATOR "Xcode")* *set(CTEST_BUILD_COMMAND "xcodebuild")* Project1 is able to do the code coverage.Here is the log snippet. *SetCTestConfiguration:CoverageCommand:/usr/bin/gcov* * Add coverage exclude regular expressions.* * target directory list [/Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/TargetDirectories.txt]* *Performing coverage* * COVFILE environment variable not found, not running bullseye* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/Continuous.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousBuild.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousConfigure.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousCoverage.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousMemCheck.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousStart.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousSubmit.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousTest.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ContinuousUpdate.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/Experimental.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalBuild.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalConfigure.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalCoverage.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalMemCheck.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalStart.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalSubmit.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalTest.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/ExperimentalUpdate.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/Nightly.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyBuild.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyConfigure.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyCoverage.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyMemCheck.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyMemoryCheck.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyStart.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlySubmit.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyTest.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/CMakeFiles/NightlyUpdate.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestUnix/out/test/CMakeFiles/Sample.dir* * Processing coverage (each . represents one file):* *."/usr/bin/gcov" -o "/Users/rajekumar/work/test-codes/TestUnix/out/test/CMakeFiles/Sample.dir" "/Users/rajekumar/work/test-codes/TestUnix/out/test/CMakeFiles/Sample.dir/main.c.gcda"* *File '/Users/rajekumar/work/test-codes/TestUnix/test/main.c'* *Lines executed:100.00% of 2* In Project 2 ctest was unable to find the .gcda. It was in /Users/rajekumar/work/test-codes/TestMac/out/test/Project.build/Debug/Sample.build/Objects-normal/x86_64/ and ctest was searching in following directories(from logs): *globbing for coverage in: /Users/rajekumar/work/test-codes/TestMac/out/CMakeFiles/ALL_BUILD.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestMac/out/CMakeFiles/Continuous.dir* * globbing for coverage in: /Users/rajekumar/work/test-codes/TestMac/out/CMakeFiles/Experimental.dir* * globbing for coverag
Re: [CMake] Code Coverage & Bullseye
As I said in my previous response, I don't know anybody who is using Xcode on the Mac, and also successfully producing a gcov coverage build. If I were you, I would: (1) use gcov on a Linux build of your software for coverage measurement, using the "Unix Makefiles" generator and the right gcov flags or (2) buy Bullseye for the Mac, as NoRulez suggested his company did because they couldn't get a reliable coverage build using gcov on the Mac This is not a ctest problem. This is a "gcov doesn't work right on the Mac" problem. If somebody would like to claim gcov does work right on the Mac, I would love to see the proof. If anybody is doing it successfully, please do share your scripts and a link to the dashboard results you get using it. (And any hints we might need to replicate it ourselves...) Thanks, David C. -- 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] Code Coverage & Bullseye
Hi, Thanks for your responses. As David mentioned I don't have to set the COVFILE if I don't have the Bullseye. I am already using the -fprofile-arcs -ftest-coverage hence .gcna & .gcno files are getting generated. Here is my CMakeLists.txt : http://pastebin.com/hQt2htkK Here is my ctest script : http://pastebin.com/CFqHkPNZ I also enabled the --Debug flag for ctest script and I found out that ctest is looking the gcov files in following directories: 1. Performing coverage 2. COVFILE environment variable not found, not running bullseye 3.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/ALL_BUILD.dir 4.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/Continuous.dir 5.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/Experimental.dir 6.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/Nightly.dir 7.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/NightlyMemoryCheck.dir 8.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/CMakeFiles/ZERO_CHECK.dir 9.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/intercepttest1/CMakeFiles/intercepttest1.dir 10.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/intercepttest2/CMakeFiles/intercepttest2.dir 11.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/sporttest1/CMakeFiles/sporttest1.dir 12.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/sporttest2/CMakeFiles/sporttest2.dir 13.globbing for coverage in: /Users/rajekumar/work/test-codes/Test/out/test/CMakeFiles/Sample.dir 14. Cannot find any GCov coverage files. 15. Cannot find any Python Trace.py coverage files. 16. Cannot find coverage.py XML file: /Users/rajekumar/work/test-codes/Test/out/coverage.xml 17. Cannot find foobar GTM coverage file: /Users/rajekumar/work/test-codes/Test/out/gtm_coverage.mcov 18. Cannot find Cache coverage file: /Users/rajekumar/work/test-codes/Test/out/cache_coverage.cmcov 19. Cannot find any coverage files. Ignoring Coverage request. But simple grep shows that .gcda .gcno are located in different directory: gcno files: ./out/intercepttest1/Project.build/Debug/intercepttest1.build/Objects-normal/x86_64/intercepttest1.gcno ./out/intercepttest2/Project.build/Debug/intercepttest2.build/Objects-normal/x86_64/intercepttest2.gcno ./out/sporttest1/Project.build/Debug/sporttest1.build/Objects-normal/x86_64/sporttest1.gcno ./out/sporttest2/Project.build/Debug/sporttest2.build/Objects-normal/x86_64/sporttest2.gcno ./out/test/Project.build/Debug/Sample.build/Objects-normal/x86_64/main.gcno gcda files: ./out/intercepttest1/Project.build/Debug/intercepttest1.build/Objects-normal/x86_64/intercepttest1.gcda ./out/intercepttest2/Project.build/Debug/intercepttest2.build/Objects-normal/x86_64/intercepttest2.gcda ./out/sporttest1/Project.build/Debug/sporttest1.build/Objects-normal/x86_64/sporttest1.gcda ./out/sporttest2/Project.build/Debug/sporttest2.build/Objects-normal/x86_64/sporttest2.gcda ./out/test/Project.build/Debug/Sample.build/Objects-normal/x86_64/main.gcda Is this the problem ??? Here is the full debug logs : http://pastebin.com/cTXFZ3tS Thanks Rajeev On Wed, Sep 17, 2014 at 6:26 PM, Bill Hoffman wrote: > On 9/17/2014 8:47 AM, NoRulez wrote: > >> Hello, >> >> since code coverage doesn't work very well with gcov and so on on Mac, >> our company decided to use bullseye for Mac OS too. >> > If you could email the COVFILE to me I could take a look. Also it might > help if you could run ctest with --debug and -VV and send those results to > me as well. Sounds like and issue with ctest. > > > > -Bill > > -- > > 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 > -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
Dear all, I had the same issue some time ago with the Boost library. The solution for me was to declare this library as "imported". Here is an example: add_library( curl UNKNOWN IMPORTED) set_property(TARGET curl PROPERTY IMPORTED_LOCATION "/opt/XXX/lib/libcurl.so.4") add_executable(xxx xxx.cpp) target_link_libraries(xxx curl) Here are some relevant links: http://www.cmake.org/pipermail/cmake/2011-June/044790.html http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries Regards, Xavier 2014-09-18 9:05 GMT+02:00 J Decker : > It shouldn't truncate paths if specified... cause of course if we want to > test against a dev version then maybe the script knows better. But neither > should it add the full path if it's not specified in the script. > > On Wed, Sep 17, 2014 at 11:59 PM, Nils Gladitz > wrote: >> >> On 09/18/2014 07:52 AM, Volker Pilipp wrote: >>> >>> That actually does the trick. But it's not nice, because there are many >>> targets in the project. >>> Actually, I do not know about any use case, where cmake should replace a >>> full path to a lib >>> by its "-l" shortcut. >> >> >> There are as far as I understand two use cases. >> >> - The library does not have a SONAME >> Linking to the library by path would embed the full path of the library >> in the target rather than just the name (which is what it does with -l or >> when the library does have a SONAME set) >> >> - The second use case I am not familiar with myself but the explanation in >> the code is: >> // Many system linkers support multiple architectures by >> // automatically selecting the implicit linker search path for the >> // current architecture. If the library appears in an implicit link >> // directory then just report the file name without the directory >> // portion. This will allow the system linker to locate the proper >> // library for the architecture at link time. >> >> >> Nils >> -- >> >> 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 > > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- 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] TARGET_LINK_LIBRARIES with full path libraries
It shouldn't truncate paths if specified... cause of course if we want to test against a dev version then maybe the script knows better. But neither should it add the full path if it's not specified in the script. On Wed, Sep 17, 2014 at 11:59 PM, Nils Gladitz wrote: > On 09/18/2014 07:52 AM, Volker Pilipp wrote: > >> That actually does the trick. But it's not nice, because there are many >> targets in the project. >> Actually, I do not know about any use case, where cmake should replace a >> full path to a lib >> by its "-l" shortcut. >> > > There are as far as I understand two use cases. > > - The library does not have a SONAME > Linking to the library by path would embed the full path of the library > in the target rather than just the name (which is what it does with -l or > when the library does have a SONAME set) > > - The second use case I am not familiar with myself but the explanation in > the code is: > // Many system linkers support multiple architectures by > // automatically selecting the implicit linker search path for the > // current architecture. If the library appears in an implicit link > // directory then just report the file name without the directory > // portion. This will allow the system linker to locate the proper > // library for the architecture at link time. > > > Nils > -- > > 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 > -- 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] TARGET_LINK_LIBRARIES with full path libraries
On 09/18/2014 07:52 AM, Volker Pilipp wrote: That actually does the trick. But it's not nice, because there are many targets in the project. Actually, I do not know about any use case, where cmake should replace a full path to a lib by its "-l" shortcut. There are as far as I understand two use cases. - The library does not have a SONAME Linking to the library by path would embed the full path of the library in the target rather than just the name (which is what it does with -l or when the library does have a SONAME set) - The second use case I am not familiar with myself but the explanation in the code is: // Many system linkers support multiple architectures by // automatically selecting the implicit linker search path for the // current architecture. If the library appears in an implicit link // directory then just report the file name without the directory // portion. This will allow the system linker to locate the proper // library for the architecture at link time. Nils -- 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
