Michael Wild skrev 2011-02-14 15:55:
Probably you could make the find_library call more robust by appropriate
PATHS options, but I currently don't have a windows available, so I
can't check whether the registry would help.
The DXSDK_DIR environment variable is set to correct location, so I use
On 02/14/2011 03:45 PM, Robert Bielik wrote:
> Eric Noulard skrev 2011-02-14 15:42:
>>> I seem to be missing something, cause I cannot find a target property
>>> for
>>> setting additional library directories (for a MSVC project)
>>
>> Usually you do not specify "additional lib directories" you sho
Eric Noulard skrev 2011-02-14 15:42:
I seem to be missing something, cause I cannot find a target property for
setting additional library directories (for a MSVC project)
Usually you do not specify "additional lib directories" you should
specify all libs you need with "target_link_libraries".
2011/2/14 Robert Bielik :
> Hi all,
>
> I seem to be missing something, cause I cannot find a target property for
> setting additional library directories (for a MSVC project)
Usually you do not specify "additional lib directories" you should
specify all libs you need with "target_link_libraries".
Hi all,
I seem to be missing something, cause I cannot find a target property for
setting additional library directories (for a MSVC project)
Help!?
TIA
/Rob
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.ki
On 08 Nov 2007, at 17:52, Bill Hoffman wrote:
Renaud Detry wrote:
You should be using FIND_LIBRARY to find the things you want to
link in, or at least finding the directory with a FIND_FILE,
and then using LINK_DIRECTORIES. LDFLAGS is a bad idea because
your users will also have to set th
Renaud Detry wrote:
OK, CMake does not know what you are doing here. It is treating
LDFLAGS like some linker flag. The idea was something like -64 or
some other linker specific flag for a platform.
Ok.
If you inject directories into the link line, you are sort of out of
luck. Why are you do
OK, CMake does not know what you are doing here. It is treating
LDFLAGS like some linker flag. The idea was something like -64
or some other linker specific flag for a platform.
Ok.
If you inject directories into the link line, you are sort of out
of luck. Why are you doing it this way?
Renaud Detry wrote:
OK, CMake does not know what you are doing here. It is treating
LDFLAGS like some linker flag. The idea was something like -64 or
some other linker specific flag for a platform.
Ok.
If you inject directories into the link line, you are sort of out of
luck. Why are you
OK, CMake does not know what you are doing here. It is treating
LDFLAGS like some linker flag. The idea was something like -64 or
some other linker specific flag for a platform.
Ok.
If you inject directories into the link line, you are sort of out
of luck. Why are you doing it this way?
Renaud Detry wrote:
As a result, Demo is linked against an obsolete installed version of
Hello, instead of the local fresh one.
Note that /tmp/lib was empty when I ran cmake.
[EMAIL PROTECTED] $ export LDFLAGS=-L/tmp/lib
OK, CMake does not know what you are doing here. It is tr
Renaud Detry wrote:
Did you build it using ADD_LIBRARY?
If yes:
PROJECT(HELLO)
ADD_LIBRARY(Hello foo.c)
ADD_EXECUTABLE(HelloBin bar.c)
TARGET_LINK_LIBRARIES(HelloBin Hello)
This is exactly what I have.
ADD_LIBRARY defines the TARGET "Hello" in the above lines. That
should link to the local lib
Renaud Detry wrote:
Did you build it using ADD_LIBRARY?
If yes:
PROJECT(HELLO)
ADD_LIBRARY(Hello foo.c)
ADD_EXECUTABLE(HelloBin bar.c)
TARGET_LINK_LIBRARIES(HelloBin Hello)
This is exactly what I have.
ADD_LIBRARY defines the TARGET "Hello" in the above lines. That should
link to the local li
Did you build it using ADD_LIBRARY?
If yes:
PROJECT(HELLO)
ADD_LIBRARY(Hello foo.c)
ADD_EXECUTABLE(HelloBin bar.c)
TARGET_LINK_LIBRARIES(HelloBin Hello)
This is exactly what I have.
ADD_LIBRARY defines the TARGET "Hello" in the above lines. That
should link to the local libHello even if you h
Zitat von Renaud Detry <[EMAIL PROTECTED]>:
Did you try to give the whole path to the lib instead of seperate
library name and path?
Can that be done without writing the lib suffix explicitly (not
cross-platform)?
And since you build the lib yourself with a cmake TARGET, the
TARGET name
Did you try to give the whole path to the lib instead of seperate
library name and path?
Can that be done without writing the lib suffix explicitly (not cross-
platform)?
And since you build the lib yourself with a cmake TARGET, the
TARGET name should be used as link dependency.
I don't
Zitat von Renaud Detry <[EMAIL PROTECTED]>:
I posted an issue about link dir order a week ago, but it seems nobody
has replied to it :-/ Is there a reason like "one should not use env
var, but FindXXX scripts instead", or did it simply slip through
unnoticed?
Did you try to give the whole path
Hi all,
I posted an issue about link dir order a week ago, but it seems nobody
has replied to it :-/ Is there a reason like "one should not use env
var, but FindXXX scripts instead", or did it simply slip through
unnoticed?
The initial post follows.
Thanks,
Renaud.
Hello,
I'm having trouble
Hello,
I'm having trouble with cmake LINK_DIRECTORIES order. I understand
cmake smart-orders link directory flags. However, flags coming from
the shell env LDFLAGS don't seem to be taken into account in this
smart sort. Is this a feature or a bug?
To illustrate the issue, I slightly modified the
19 matches
Mail list logo
