On Wednesday 12 September 2007 15:45:52 Bill Hoffman wrote:
> Jesper Eskilson wrote:
> > Really you should be using full paths to libraries and not
> > LINK_DIRECTORIES anyway.
> >
> >
> > Why not? Is that a general advice about LINK_DIRECTORIES?
>
> Yes, if cmake knows the full path to the library
Reminder: The early registration deadline for the Developer's Training
Week is quickly approaching. Please register by September 15, 2007 to
take advantage of the reduced registration fee.
--
Kitware is pleased to announce the D
Turns out that it was a newbie mistake..
Building different platforms in the main
directory isn't a good idea.After I downloaded again
and made different target directories for each platform
( osx-ppc, osx-intel, linux32, linux64, etc..)
and did a configure in there - everything worked
So, life is slightly trickier since you are using a PrivateFramework.
We never requested the CMake folks handle this explicitly, though
there may already be enough built-in flexibility to handle this.
For the library:
FIND_LIBRARY(CHUD_LIBRARY
NAMES CHUD
PATHS /System/Library/PrivateFrame
Hello all !
I have an unexpected problem with CMake (v 2.4.2) command "FLTK_WRAP_UI".
In fact, when I configure CMake for my project, i have this message :
"In CMake 2.2 the FLTK_WRAP_UI command sets a variable to the list of
source files that should be added to your executable or library. It app
Bill Hoffman wrote:
> That still does not make sense. If visual studio does not know where
> the library is, then it will not just rebuild all the time. I
> would like to see an example that shows this problem, as I suspect at
> the end of the day it is most likely a cmake bug. Can you at lea
Jesper Eskilson wrote:
Really you should be using full paths to libraries and not
LINK_DIRECTORIES anyway.
Why not? Is that a general advice about LINK_DIRECTORIES?
Yes, if cmake knows the full path to the library it can handle it much
better.
If you just specify the name of the directo
Bill Hoffman wrote:
> Jesper Eskilson wrote
>>
>> Well, that turned out to be a little hasty conclusion.
>>
>> In case of linking with a DLL, having paths to both the dll and import
>> lib in LINK_DIRECTORIES avoids relinking. So far, so good.
>>
>> However, I still get relinks due to a dependency
Jesper Eskilson wrote:
Christian Ehrlicher wrote:
Von: Jesper Eskilson
An: Jack Kelly
CC: cmake@cmake.org
Betreff: Re: [CMake] Project being (unnecessarily) relinked
Jack Kelly wrote:
Is there any reason why
IF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
LINK_DIRECTORIES("/path/
Christian Ehrlicher wrote:
>> Von: Jesper Eskilson
>> An: Jack Kelly
>> CC: cmake@cmake.org
>> Betreff: Re: [CMake] Project being (unnecessarily) relinked
>
>> Jack Kelly wrote:
>>> Is there any reason why
>>>
>>> IF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
>>> LINK_DIRECTORIES("/path/to/debug/li
Jesper Eskilson wrote
Well, that turned out to be a little hasty conclusion.
In case of linking with a DLL, having paths to both the dll and import
lib in LINK_DIRECTORIES avoids relinking. So far, so good.
However, I still get relinks due to a dependency on a static library.
In this case,
> Von: Jesper Eskilson
> An: Jack Kelly
> CC: cmake@cmake.org
> Betreff: Re: [CMake] Project being (unnecessarily) relinked
> Jack Kelly wrote:
> > Is there any reason why
> >
> > IF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
> > LINK_DIRECTORIES("/path/to/debug/lib")
> > ELSE("${CMAKE_BUILD_TYPE}
Jack Kelly wrote:
> Is there any reason why
>
> IF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
> LINK_DIRECTORIES("/path/to/debug/lib")
> ELSE("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
> LINK_DIRECTORIES("/path/to/release/lib")
> ENDIF("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
>
> won't work for you?
Jesper Eskilson wrote
Well, that turned out to be a little hasty conclusion.
In case of linking with a DLL, having paths to both the dll and import
lib in LINK_DIRECTORIES avoids relinking. So far, so good.
However, I still get relinks due to a dependency on a static library. In
this case, I
Jesper Eskilson wrote:
Jesper Eskilson wrote:
Mike Jackson wrote:
On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote:
A related question: if I include an external project in my solution
using
include_external_msproject(Bar ../../Bar/Bar.vcproj)
can I later refer to this project using
tar
Jesper Eskilson wrote:
Mike Jackson wrote:
On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote:
A related question: if I include an external project in my solution
using
include_external_msproject(Bar ../../Bar/Bar.vcproj)
can I later refer to this project using
target_link_libraries(Foo B
16 matches
Mail list logo