You can find more info in this bug report:
http://public.kitware.com/Bug/view.php?id=3832
Brad is currently on holiday, but I hope once he return he will fix this.
Greetings,
Steven
On 12/30/07, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> Hi people.
> Sometimes I feel that CMake tries to be smar
Hi people.
Sometimes I feel that CMake tries to be smarter then me when dealing
with library names. For instance, suppose the following setup:
* project
CMakeLists.txt
test.cpp
video.a
CMakeLists.txt:
add_executable(test test.cpp)
target_link_libraries(test ${CMAKE_SOURCE_
Ugh, sorry, accidentally botched the first replies because the
original reply was not to the list.
On 12/28/07, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 28, 2007 at 05:40:59PM -0800, E. Wing wrote:
> > I didn't know cross-compiling was a feature now.
>
> Yes, works very well once you
On 12/28/07, Rodolfo Lima <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 28, 2007 at 05:40:59PM -0800, E. Wing wrote:
> > I didn't know cross-compiling was a feature now.
>
> Yes, works very well once you provide a 'toolchain file' with the correct
> setup.
>
> > But the FindLua, FindFreeType modules sho
Let me specify a valid use case for this. Suppose you have a project
with an internal library (call it convenience library, in gnu terms).
Then you want to debug the main application, but due to speed issues,
you want the internal library to remain compiled with optimizations
turned on. In this cas
I'm using the CVS version.
"cl" is unknown in my environment (not defined by the %PATH%
variable), so CMake will probably get it from the registry.
But I want to use the path that CMake found already inside my
CMakeList.txt, not search it again ;-).
On 12/29/07, Steven Van Ingelgem <[EMAIL PRO
On Saturday 29 December 2007, Steven Van Ingelgem wrote:
> I want to use "MASM" (ml64.exe on VS2005) to compile some files, but
> how can I find it's directory?
> If I know where the "cl.exe" is located it's the same directory +
> "/x86_64", but the variable "CMAKE_C_COMPILER" only contains "cl"
>
I want to use "MASM" (ml64.exe on VS2005) to compile some files, but
how can I find it's directory?
If I know where the "cl.exe" is located it's the same directory +
"/x86_64", but the variable "CMAKE_C_COMPILER" only contains "cl"
(which is not in the path!).
What would my options be here?
Than
On Dec 29, 2007 10:20 AM, Matt Williams <[EMAIL PROTECTED]> wrote:
>
> What I was hoping would be possible is for me to be able to run a cmake macro,
> something like
> INSPECT_CPP_MACRO(_BUILD_MODULE_ "../include/PlatformInformation.h"
> BUILD_MODULE) which would compile and run the header file an
On Saturday 29 December 2007, Rodolfo Schulz de Lima wrote:
> > By setting the mode to ONLY cmake will look ONLY in the directories with
> > the
> > CMAKE_FIND_ROOT_PATH prefix.
>
> Yes, I do this. The problem is that those scripts hardwire some default
> paths to the native places where headers an
"Alexander Neundorf" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Why do you need that at build time ?
If the lib is built in the same project, you can get the flags directly
from
there.
In all other cases it should be possible to write a cmake test to figure
it
out or to load
"Alexander Neundorf" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
No, that's not possible.
Is there any interest in making this possible?
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cma
By setting the mode to ONLY cmake will look ONLY in the directories with
the
CMAKE_FIND_ROOT_PATH prefix.
Yes, I do this. The problem is that those scripts hardwire some default
paths to the native places where headers and libraries are found. When we
cross-compile, those defaults should be c
Hi,
I am writing a cmake system for a project, but at one point I need to decide
whether a certain module of it should be built or not. Now, there's some
preprocessor logic in one of the header files which sets a preprocessor
#define to 1 or 0 and that is used to decide whether to include the h
On Saturday 29 December 2007, Rodolfo Lima wrote:
> Hi all,
> I've been exercising cmake-cvs's cross-compiling capabilities and I've
> noticed that the way several Find* scripts work doesn't behave well with
> cross-compiling.
>
> Usually when doing this kind of builds (at least in linux), one have
On Friday 28 December 2007, Moe Alkhafaji wrote:
> I have another question...
>
> I did notice that eclipse 3.3 has become extremely impressive on C/C++
> development front. I am more inclined now to give it a shot to see if
> it can provide me with more than what xcode 3.0 can for C/C++
> programm
On Friday 21 December 2007, Rodolfo Schulz de Lima wrote:
> Is there a way to override CMAKE_BUILD_TYPE per target?
> For instance, I'd like to write:
>
> set_target_properties(target PROPERTIES BUILD_TYPE Release)
>
> And have my target compiled in Release mode regardless of the current value
> of
On Friday 21 December 2007, Rodolfo Lima wrote:
> How can I set an executable compiler flags based on the result of the
> compilation of another target? Or, with another words, can I set a
> directory's COMPILER_FLAGS at build time?
Why do you need that at build time ?
If the lib is built in the s
18 matches
Mail list logo
