Re: [CMake] Setting default make options for Makefiles generator

If none of the developers sees any important issue with this proposal, I'll submit a feature request based on what has been discussed in the current thread. Thanks all, On Thu, Mar 5, 2009 at 11:23 AM, Adolfo Rodríguez dof...@gmail.com wrote: On Thu, Mar 5, 2009 at 11:17 AM, Kito

Re: [CMake] Call a macro through a variable. Possible or not?

Thanks for your reply Dmitriy, but... it does not solve what I wanted to do. If I understand the syntax page correctly, it says you can invoke the macro/function named command and pass arguments stored in variable Foo using the syntax command(${Foo}). But that's not what I meant. I was looking

Re: [CMake] Call a macro through a variable. Possible or not?

On 06.03.09 09:37:37, Marcel Loose wrote: Thanks for your reply Dmitriy, but... it does not solve what I wanted to do. I think with the Quote Dmitriy tried to tell you that this isn't possible. CMake is not an object-oriented or functional language, its more like a procedural language.

Re: [CMake] Call a macro through a variable. Possible or not?

Marcel, I'm sorry. I supposed there is special command command to invoke code stored to variable. I reread manual once more and did not find anything like meta-programing for CMake. BTW, why do you need this feature? Regards, Dmitriy Friday, March 6, 2009, 10:37:37 AM, you wrote: ML Thanks

Re: [CMake] Call a macro through a variable. Possible or not?

Hi Dmitriy, I don't really need this feature, but it would have made some tasks easier to program in CMake. So, I thought, if it's possible, then how should I do it. But, as it turns out it's not possible, I'll have to find a different solution. Thanks anyway. Best regards, Marcel Loose. On

Re: [CMake] Call a macro through a variable. Possible or not?

On Fri, Mar 6, 2009 at 2:40 AM, Marcel Loose lo...@astron.nl wrote: Hi Dmitriy, I don't really need this feature, but it would have made some tasks easier to program in CMake. So, I thought, if it's possible, then how should I do it. But, as it turns out it's not possible, I'll have to find

[CMake] Documentation bug(?) in CheckC(XX)SourceCompiles

Hi, I found out the hard way -- and after inspecting the macro definition of CheckCSourceCompiles and CheckCXXSourceCompiles -- that the second argument (VAR) is a cache variable. I think the documentation should be clearer about that. Best regards, Marcel Loose.

[CMake] Windows Drivers and CMake

Hi, I'm trying to use cmake to build windows drivers. Currently I use a makefile, a source file and the WDK shell environment, then I just type build. Is there a way to make it work with CMake ? Thanks -- Corentin Chary http://xf.iksaif.net ___ Powered

Re: [CMake] Fwd: setting environment variable through cmake

2009/2/17 Philip Lowman phi...@yhbt.com On Mon, Feb 16, 2009 at 11:03 PM, ankit jain ankitgu...@gmail.comwrote: -- Forwarded message -- From: ankit jain ankitgu...@gmail.com Date: 2009/2/17 Subject: Re: [CMake] setting environment variable through cmake To: Philip

[CMake] CheckCSourceCompiles (revisited)

Hi all, With respect to my previous post. Is it possible to somehow reset the result variable from CheckCSourceCompiles(SOURCE VAR)? I wanted to run a number of tests in a foreach loop, using the same C-code snippet, but with one CMake variable being substituted, but I noticed that the test is

Re: [CMake] add_dependencies with an imported target

Joachim de Vries wrote: CMake version 2.6 Mac OSX 10.5 XCode 3.0 My problem is that I have the situation I described in the bottom. I have one app and one lib in one project. If I change something in my lib everything is compiled and the app starts but the app didn't link the lib again.

Re: [CMake] Windows Drivers and CMake

You could encapsulate the configuration (cmake) and build (make, or whatever build tool you use) in a shell script (called build!). Would that work for you? HTH, Adolfo On Fri, Mar 6, 2009 at 2:30 PM, Corentin Chary corentin.ch...@gmail.comwrote: Hi, I'm trying to use cmake to build windows

Re: [CMake] Setting default make options for Makefiles generator

Adolfo Rodríguez wrote: If none of the developers sees any important issue with this proposal, I'll submit a feature request based on what has been discussed in the current thread. Thanks all, I am not sure I like the idea. It is too make specific. The makefiles that cmake generates

Re: [CMake] Documentation bug(?) in CheckC(XX)SourceCompiles

On 6. Mar, 2009, at 14:13, Marcel Loose wrote: Hi, I found out the hard way -- and after inspecting the macro definition of CheckCSourceCompiles and CheckCXXSourceCompiles -- that the second argument (VAR) is a cache variable. I think the documentation should be clearer about that.

Re: [CMake] CheckCSourceCompiles (revisited)

On 6. Mar, 2009, at 14:50, Marcel Loose wrote: Hi all, With respect to my previous post. Is it possible to somehow reset the result variable from CheckCSourceCompiles(SOURCE VAR)? I wanted to run a number of tests in a foreach loop, using the same C-code snippet, but with one CMake variable

Re: [CMake] slight problem with CTest documentation

Philip Lowman wrote: The CTest documentation online appears like it wasn't generated from the 2.6.3 source release. Just noticed this by accident tonight and wanted to mention it. http://www.cmake.org/cmake/help/ctest2.6docs.html#command:ctest_update * *|ctest_submit|*: Submits the

Re: [CMake] Documentation bug(?) in CheckC(XX)SourceCompiles

After further inspection, I think my observation holds true for all Check*.cmake files in the Modules directory, not just the CheckC(XX)SourceCompiles files. Marcel Loose On Fri, 2009-03-06 at 16:04 +0100, Michael Wild wrote: On 6. Mar, 2009, at 14:13, Marcel Loose wrote: Hi, I found

Re: [CMake] Documentation bug(?) in CheckC(XX)SourceCompiles

Marcel Loose wrote: After further inspection, I think my observation holds true for all Check*.cmake files in the Modules directory, not just the CheckC(XX)SourceCompiles files. It is a cache variable so that the test is not run over and over each time CMake is run. unset is in cmake 2.6.3.