Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Andreas Naumann
Am 17.09.2014 22:00, schrieb Alexander Neundorf: On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote: ... I suppose it is the line LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib /

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
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. Thank you very much for your help. Volker On Wed, Sep 17, 2014 at 10:40 PM, j s wrote

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread j s
Would it be possible to set something like: TARGET_LINK_LIBRARIES(myexe -L/opt/XXX/lib -lcurl) in the path? On Wed, Sep 17, 2014 at 9:33 AM, Nils Gladitz wrote: > On 09/17/2014 02:50 PM, Volker Pilipp wrote: >> >> I see that /usr/lib64 (where libcurl.so.3 resides) is before >> /opt/XXX/lib (wher

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Alexander Neundorf
On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote: ... > I suppose it is the line > LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g > cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib > /../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-li

Re: [CMake] Get Visual Studio target Arch

2014-09-17 Thread Alexey Petruchik
> No "CMake time" decisions are possible based on the configuration I have a project that uses some unix libraries. I use find_package() to locate them. On Windows platform find_package() obviously fails so I maintain folder with prebuilt binaries. So my CMakeLists.txt looks like: if (${CMAKE_SYS

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Nils Gladitz
On 09/17/2014 02:50 PM, Volker Pilipp wrote: I see that /usr/lib64 (where libcurl.so.3 resides) is before /opt/XXX/lib (where libcurl.so.4 resides). That's why g++ links against the wrong library. However, this problem would not occur if I could stop cmake from replacing /opt/XXX/lib/libcurl.so b

Re: [CMake] Code Coverage & Bullseye

2014-09-17 Thread Bill Hoffman
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 s

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
> Run e.g. > echo "int main() {}"|/opt/XXX/bin/g++ -xc++ - -v > The output is Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/opt/XXX Thread model: posix gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/XXX/

Re: [CMake] Code Coverage & Bullseye

2014-09-17 Thread NoRulez
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. I hope it helps Am 17.09.2014 um 14:22 schrieb David Cole via CMake : >> I am trying to configure the code coverage using the ctest script. I >> took help from : ht

Re: [CMake] Code Coverage & Bullseye

2014-09-17 Thread David Cole via CMake
> I am trying to configure the code coverage using the ctest script. I > took help from : http://www.cmake.org/Wiki/CTest/Coverage That wiki page was mostly written in 2007 and 2009. You may want to refer to something more recent than that, and something that's proven to work, like an existing das

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Nils Gladitz
On 09/17/2014 02:17 PM, Volker Pilipp wrote: On Wed, Sep 17, 2014 at 2:04 PM, Nils Gladitz mailto:nilsglad...@gmail.com>> wrote: On 09/17/2014 01:50 PM, Volker Pilipp wrote: I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) -> no effect

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
On Wed, Sep 17, 2014 at 2:04 PM, Nils Gladitz wrote: > On 09/17/2014 01:50 PM, Volker Pilipp wrote: > >> I did so and found the following strange behaviour >> >> link_directories( /opt/XXX/lib ) -> no effect >> but >> link_directories( /opt/ ) -> -L/opt (?!) >> > > Probably the same logic as fo

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Nils Gladitz
On 09/17/2014 01:50 PM, Volker Pilipp wrote: I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) -> no effect but link_directories( /opt/ ) -> -L/opt (?!) Probably the same logic as for target_link_libraries(). E.g. implicit link directories aren't repeated as

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) -> no effect but link_directories( /opt/ ) -> -L/opt (?!) Volker On Wed, Sep 17, 2014 at 1:32 PM, J Decker wrote: > can't just add link_directories( /opt/XXX/lib ) ? > > On Wed, Sep 17, 2014 at 3:58 AM, Nil

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread J Decker
can't just add link_directories( /opt/XXX/lib ) ? On Wed, Sep 17, 2014 at 3:58 AM, Nils Gladitz wrote: > On 09/17/2014 12:29 PM, Volker Pilipp wrote: > >> I have encountered the following problem with cmake 3.0.1. >> Under certain circumstances TARGET_LINK_LIBRARIES replaces >> "/path/to/libXXX

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
On Wed, Sep 17, 2014 at 12:58 PM, Nils Gladitz wrote: > On 09/17/2014 12:29 PM, Volker Pilipp wrote: > >> I have encountered the following problem with cmake 3.0.1. >> Under certain circumstances TARGET_LINK_LIBRARIES replaces >> "/path/to/libXXX.so" by "-lXXX". The problem occurred when I used a

Re: [CMake] [Cdash] Show results from the bullseye coverage in CDash

2014-09-17 Thread 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

Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Nils Gladitz
On 09/17/2014 12:29 PM, Volker Pilipp wrote: I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces "/path/to/libXXX.so" by "-lXXX". The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /o

[CMake] TARGET_LINK_LIBRARIES with full path libraries

2014-09-17 Thread Volker Pilipp
I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces "/path/to/libXXX.so" by "-lXXX". The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES.

Re: [CMake] [Cdash] Show results from the bullseye coverage in CDash

2014-09-17 Thread 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

Re: [CMake] [Cdash] Show results from the bullseye coverage in CDash

2014-09-17 Thread NoRulez
Sorry for the long response time but we are currently in a release stage. 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. Currently CMake 3.0.1 and CDash 2.2.2 are used Bes