If it is something not being built by cmake, then a full path should
be used,
and cmake should do the right thing. LINK_DIRECTORIES should be
used as a last resort. If the library does not exist at cmake run
time, because
it will be built by the cmake project, then it should work. If the
On 10/9/07, David Cole <[EMAIL PROTECTED]> wrote:
>
> The problem (from a CMake perspective) is how to go about giving
> override control of that setting to CMakeLists.txt files / developers
> using CMake. If anybody has a reasonable suggestion of how to achieve
> this in a non-Xcode-centric way (i
On 10/9/07, Mike Jackson <[EMAIL PROTECTED]> wrote:
> I think this is more of an Xcode issue than a Cmake issue. Xcode by
> default will have 2 types of "Configurations", Debug and Release.
> Xcode _will_ make the subdirectories (just like VS) named after the
> configuration. This is hard coded int
On Oct 9, 2007, at 12:27 PM, Sylvain Benner wrote:
This has to be this way, or the cmake generated projects will not
be able to find
libraries in other projects of the same build type. Can someone
explain the issue
with this? We are using this for VTK and several other larger
project
Sylvain Benner wrote:
This has to be this way, or the cmake generated projects will not be
able to find
libraries in other projects of the same build type. Can someone
explain the issue
with this? We are using this for VTK and several other larger
projects, and
it works fine.
-Bill
Ok I
This has to be this way, or the cmake generated projects will not be
able to find
libraries in other projects of the same build type. Can someone
explain the issue
with this? We are using this for VTK and several other larger
projects, and
it works fine.
-Bill
Ok I understand but library
Sylvain Benner wrote:
I then generate Xcode projects, but they give me a warning that
/path/to/Debug (or /path/to/Release) doesn't exist in the linker flag
-L/path/to/{Debug,Release} (and fail because there are alongside
libraries being pulled it). Apparently, cmake added the linker flag
-L/pat
I then generate Xcode projects, but they give me a warning that
/path/to/Debug (or /path/to/Release) doesn't exist in the linker flag
-L/path/to/{Debug,Release} (and fail because there are alongside
libraries being pulled it). Apparently, cmake added the linker flag
-L/path/to/Debug with the abo
KSpam wrote:
This was an annoyance I had with Visual Studio as well, and I was able to work
around it fairly easily. I have CMAKE_CONFIGURATION_TYPES set when I am
building in Visual Studio. I expect that this would be similar for Xcode.
All I do is prepend "../" to the output name, and I se
This was an annoyance I had with Visual Studio as well, and I was able to work
around it fairly easily. I have CMAKE_CONFIGURATION_TYPES set when I am
building in Visual Studio. I expect that this would be similar for Xcode.
All I do is prepend "../" to the output name, and I set the OUTPUT_N
In my experience, it is Xcode that is adding the Debug or Release
additions to your path. I think there is something in the project
settings where you can tell it where to put the built binaries. Of
course that will be wiped out next time you change anything in the
CMake files as cmake will
Hi,
I add required libraries to my project with
TARGET_LINK_LIBRARIES(target /path/to/library)
I then generate Xcode projects, but they give me a warning that
/path/to/Debug (or /path/to/Release) doesn't exist in the linker flag
-L/path/to/{Debug,Release} (and fail because there are alongside
li
12 matches
Mail list logo
