Hi Bill,
I've created an empty foo.c like the following
#include stdio.h
void main(void)
{
}
and a CMakeLists.txt the same as you offered and I put them into the
C:\CMakeTest folder and made a folder Bin inside this folder.
I've changed my directory to the bin directory of CMake and
Quoting Charlene Tsai [EMAIL PROTECTED]:
Hi Pau Garcia i Quiles,
Thanks for the suggestion. It works well on linux and Windows.
However, it is still not happy with MinGW. To compile with MinGW, we
need to have
TARGET_LINK_LIBRARIES( my_lib ITKCommon ITKIO libxml2)
and set
Brandon Van Every escreveu:
I think you will need to do a COMMAND cmake -P myscript.cmake.
myscript.cmake should contain an EXECUTE_PROCESS that does what you
want, then interprets the return codes however you want. Then you'd
message(SEND_ERROR ...) or message(FATAL_ERROR ...) to indicate
Hi, I'd like to mention bug #6137 in bug tracker, where I've written a
patch to cmake (both 2.4 and 2.5-cvs) where I add a target property
(SOURCES) to get the sources assigned to a target. As I say there, I'm
using it to properly implement header precompilation because I need to
add the
Rodolfo Lima wrote:
David Cole escreveu:
What about:
MESSAGE(X${CMAKE_CXX_FLAGS}X)
Same thing.
There is nothing in CMAKE_CXX_FLAGS -- it's just the behavior of MESSAGE
when you pass it a list instead of a single string...
I think there is... another proof:
if(${CMAKE_CXX_FLAGS} STREQUAL
-Original Message-
From: Daniel [mailto:[EMAIL PROTECTED]
Sent: 14 December 2007 15:23
To: Josef Karthauser
Cc: CMake ML
Subject: Re: [CMake] Compilation speed with CMake/NMake combination,
making it faster?
[cut]
Don't forget about the fast targets, I make heavy use of them.
Bill Hoffman escreveu:
What is in your CMakeCache.txt file?
Also, does this happen with a very simple one line cmakelist.txt file?
add_library(foo.cxx)
(of course you will have to create an empty foo.cxx)
I always test with a clean CMakeCache.txt (i.e., without it), and don't
even add a
Josef Karthauser wrote:
So we’ve got a fairly sizable amount of code described in the CMake
framework now, about 10 or so libraries, and 4 projects which consume
them. We’re now hitting upon compilation time as an issue, as it takes
much longer than our previous framework did. I’m wondering
Rodolfo Lima wrote:
Hi, I'd like to mention bug #6137 in bug tracker, where I've written a
patch to cmake (both 2.4 and 2.5-cvs) where I add a target property
(SOURCES) to get the sources assigned to a target.
Thanks, we're looking at the patch. We typically have constructed the
set of source
Bill Hoffman escreveu:
Rodolfo Schulz de Lima wrote:
function call_command()
{
-- I think that passing 'COMMAND' is not needed, but it's ok if
-- one cares about maintaining the cmake script syntax.
ret = execute_process(COMMAND, whatever);
-- do something with ret
return
Alan W. Irwin wrote:
I am struggling with understanding the recursive make system that
CMake normally employs
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it just
evaluates target-level dependencies with
Bill Hoffman escreveu:
OK, I know I will regret this, but how would lua help here? Other than
the myscript.cmake would be myscript.lua and the syntax would by
slightly different, it would be the exact same thing. The issue is that
cmake and whatever language it uses is not around at build
What about:
MESSAGE(X${CMAKE_CXX_FLAGS}X)
There is nothing in CMAKE_CXX_FLAGS -- it's just the behavior of MESSAGE
when you pass it a list instead of a single string...
On 12/13/07, Rodolfo Lima [EMAIL PROTECTED] wrote:
Hi, I've being trying cmake 2.5 from CVS and I've come with some
unwanted
Cristian Bidea escreveu:
Hello
Is it possible to set some C_FLAGS per target?! I know about the
global variable CMAKE_C_FLAGS but I don't need all the flags for all
the targets in the project.
Thank you!
I think you can set it with set_target_properties, for example:
Hello
Is it possible to set some C_FLAGS per target?! I know about the
global variable CMAKE_C_FLAGS but I don't need all the flags for all
the targets in the project.
Thank you!
___
CMake mailing list
CMake@cmake.org
In my setup, the xrc resource file is generated from another file
(wxformbuilder format) by a custom command, which calls wxformbuilder to
convert it to xrc. This one is input to WXWIDGETS_ADD_RESOURCES.
Since WXWIDGETS_ADD_RESOURCES tries to read from xrc BEFORE it is
created by
Rodolfo Schulz de Lima wrote:
Bill Hoffman escreveu:
Rodolfo Schulz de Lima wrote:
function call_command()
{
-- I think that passing 'COMMAND' is not needed, but it's ok if
-- one cares about maintaining the cmake script syntax.
ret = execute_process(COMMAND, whatever);
-- do
Bill Hoffman escreveu:
Right, so you want the execute_process to be executed at build time,
basically convert the lua/cmake to the right code for the generator.
Really has nothing to do with the language used. You want the
call_command function to run at build time. Your example is simple
Rodolfo Schulz de Lima wrote:
I see... after some thought I understood that the user would
(rightfully) expect that call_command would be executed in build time.
What if it he executes something that the generator cannot handle (open
a socket and send the return value, for example)? This
You might also want to consider visual studio builds. It will build two
targets at the same time if there is no dependency between them, and
would have the same issue.
-Bill
___
CMake mailing list
CMake@cmake.org
On 2007-12-14 10:32-0500 Brad King wrote:
Alan W. Irwin wrote:
I am struggling with understanding the recursive make system that
CMake normally employs
CMake employs a 2-level make recursion system that is independent of the
directory structure. The first level never builds anything...it
But you should be able to put your custom command in its own custom target
and then use ADD_DEPENDENCIES to make the custom target build *before* any
build steps for the library...
Have you tried that?
HTH,
David
On 12/14/07, Bill Hoffman [EMAIL PROTECTED] wrote:
Josef Karthauser wrote:
I
On Dec 14, 2007 1:28 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
Bill Hoffman escreveu:
I am thinking the lua stuff is pretty much dead at this point (don't get
upset :) ), if you see Ken's post here:
I read the whole thread and didn't find any good reason not to adopt
lua.
Bill Hoffman escreveu:
Can you give an example that shows the unwanted semicolons?
For sure. Here's the setup:
test.c:
int main() {}
CMakeLists.txt:
list(APPEND CMAKE_C_FLAGS -Wall)
add_executable(test test.c)
when we run make, we have:
gcc: no input files
/bin/sh: -Wall: not found
make[2]:
On 2007-12-14 12:49-0500 Bill Hoffman wrote:
You might also want to consider visual studio builds. It will build two
targets at the same time if there is no dependency between them, and would
have the same issue.
Currently, we have had no reports about such problems. However, our windows
Rodolfo Schulz de Lima wrote:
Bill Hoffman escreveu:
Can you give an example that shows the unwanted semicolons?
For sure. Here's the setup:
test.c:
int main() {}
CMakeLists.txt:
list(APPEND CMAKE_C_FLAGS -Wall)
add_executable(test test.c)
OK, list append is having the problem. I will
Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time as
part of a custom_command might be a good feature.
Well, if one of the reasons not to use lua is to avoid calling cmake
during build, why do it with a cmake script is a good thing?
I am thinking the
Brandon Van Every escreveu:
Certain CMake people want to *say* it was conclusive, so that the
issue will go away, but it wasn't conclusive. In particular, I have
to note the self-selecting nature of the CMake community. If you
stick around and duke it out with CMake, there's a pretty good
Bill Hoffman wrote:
CMakeLists.txt:
list(APPEND CMAKE_C_FLAGS -Wall)
add_executable(test test.c)
OK, list append is having the problem. I will try and figure out why
it has the space. For now, you could try this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall)
OK, Dave Cole, just pointed
Bill Hoffman escreveu:
I never said that it was a bad thing to call cmake during the build we
do it all the time. That was the suggestion from Brandon that started
this whole thread (which I said I would regret :) ). To go one step
further from the suggestion would be to make it easy to
On Dec 14, 2007 2:34 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
So, although odd that it has a space in it, it is benign.
It's malignant from the standpoint of IF. CMAKE_C_FLAGS is being
initialized to a nonempty string. That means
if(CMAKE_C_FLAGS) will succeed. Should file a bug or fix it.
On Dec 14, 2007 7:43 AM, Rodolfo Lima [EMAIL PROTECTED] wrote:
I think there is... another proof:
if(${CMAKE_CXX_FLAGS} STREQUAL )
MESSAGE(equal!)
else(${CMAKE_CXX_FLAGS} STREQUAL )
MESSAGE(not equal!)
endif(${CMAKE_CXX_FLAGS} STREQUAL )
This returns equal! in my system...
If
Brandon Van Every wrote:
On Dec 14, 2007 2:34 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
So, although odd that it has a space in it, it is benign.
It's malignant from the standpoint of IF. CMAKE_C_FLAGS is being
initialized to a nonempty string. That means
if(CMAKE_C_FLAGS) will succeed.
Rodolfo Schulz de Lima wrote:
Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time as
part of a custom_command might be a good feature.
Well, if one of the reasons not to use lua is to avoid calling cmake
during build, why do it with a cmake script is a
Bill Hoffman escreveu:
It really boils down to this: There is no way we can ever stop
supporting the current cmake language. It would be a huge break in
backwards compatibility. The prospect of having two languages forever
is not something I would like to do either. So, we will continue
On Dec 14, 2007 2:29 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
I didn't quite get what you mean here about 'self-selecting nature of
CMake community' (sorry, English language barrier).
It means, people who like CMake the way it is, tend to stick around.
People who have a serious
- Original Message -
From: Brandon Van Every
Date: 12/14/2007 12:04 PM
Certain CMake people want to *say* it was conclusive, so that the
issue will go away, but it wasn't conclusive. In particular, I have
to note the self-selecting nature of the CMake community. If you
stick around and
On Dec 14, 2007 2:38 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
It really boils down to this: There is no way we can ever stop
supporting the current cmake language. It would be a huge break in
backwards compatibility.
Gee I'm getting paid to migrate a huge build system, from ancient
crufty
Mike Jackson escreveu:
Don't forget that time is a real barrier, not a perceived one. How
long would you wait for the lua implementation. What other features
would you be willing to give up in order to have lua in x number of
months? Remember Kitware has to pay their employees. They get money
On Dec 14, 2007, at 3:19 PM, Brandon Van Every wrote:
Ken showed proof of concept for Lua. It's too hard would be a
completely silly argument at this point.
And for what I saw, its implementation could be better (no unpack,
etc...).
Yeah. In fact I saw his response of well, we
Brandon Van Every escreveu:
On Dec 14, 2007 7:43 AM, Rodolfo Lima [EMAIL PROTECTED] wrote:
If CMAKE_CXX_FLAGS is actually null, then your script should terminate
with an error. Correct syntax is either plain CMAKE_CXX_FLAGS or
${CMAKE_CXX_FLAGS}. What you've written would work only if the
Joshua Jensen escreveu:
Brandon asked me a short while ago to post a response I had made to a
thread on Sweng-Gamedev. I don't post this to fan flames or to even
form an opinion. It is just my experience in the matter.
What is written in the response is quite like what I feel when using
On Dec 14, 2007 3:27 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
It is clear that
CMake won't support Lua (and it's right to do so, because of backwards
compatibility), so a fork is the only viable option.
I'm not willing to concede the clarity. As I just wrote, backwards
On Dec 14, 2007 3:54 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
I look to a cmake script and it YELLS at me, with all
those upper cased letters.
The newfangled style is to write your commands in lower case. All the
CMake CVS documentation is in this style now. I've started to adopt
On Dec 14, 2007 3:01 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
Bill Hoffman escreveu:
OK, Dave Cole, just pointed out that list is the wrong thing to use
here. The CMAKE_C_FLAGS variable is supposed to be a string and not a
list. If you used list(APPEND more than once it would
Brandon Van Every escreveu:
I'm not willing to concede the clarity. As I just wrote, backwards
compatibility is an issue to solve, not a dealbreaker. As for labor,
there's already a quorum of people interested in the issue, and CMake
forks have been threatened before. I'd like to see people
Brandon Van Every escreveu:
I can't call set(var value) ugly. I can call it slightly verbose,
as opposed to var=value.
Ugliness is highly subjective. I'm handsome, by the way :)
It is boring precisely because it is *not* error prone. It is a way
of ensuring against errors. If you haven't
Pau Garcia i Quiles escreveu:
The most powerful reason not to use Lua is adding Lua effectively forces
you to know two languages (Lua and CMake script) to use CMake.
You know, you could choose either one, not necessarily both...
Regards,
rod
___
Quoting Rodolfo Schulz de Lima [EMAIL PROTECTED]:
Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time
as part of a custom_command might be a good feature.
Well, if one of the reasons not to use lua is to avoid calling cmake
during build, why do it
On 2007-12-14 18:54-0200 Rodolfo Schulz de Lima wrote:
[...]What I mostly miss in CMake is a nicer syntax. I look
to a cmake script and it YELLS at me, with all those upper cased letters.
As a point of information that depends to a certain extent on what style of
CMake scripting you decide to
On Dec 14, 2007 6:09 PM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
Quoting Rodolfo Schulz de Lima [EMAIL PROTECTED]:
Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time
as part of a custom_command might be a good feature.
Well, if one of the
On 2007-12-14 09:53-0800 Alan W. Irwin wrote:
Obviously, CMake 2.4.x users are stuck with these file dependency issues and
their workarounds, but for obvious reasons and especially for the parallel
build case I hope the complete rework of the CMake dependency system that
has been mentioned
On Friday 14 December 2007, Brandon Van Every wrote:
On Dec 14, 2007 2:38 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
It really boils down to this: There is no way we can ever stop
supporting the current cmake language. It would be a huge break in
backwards compatibility.
Gee I'm getting
On Tuesday 04 December 2007, Mike Jackson wrote:
I need to test for icc/icpc (The intel compiler). What would be the
best way to do that?
With cmake cvs you can check the compiler id (CMAKE_C_COMPILER_ID or something
similar), with cmake 2.4.x you have to check the filename of the compiler I
On Dec 14, 2007 6:04 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
One of the huge advantages of the CMake scripting that I don't believe has
been emphasized enough in this discussion is it is a small, very easy to
learn language. I like it that way, and I believe that quality attracts
others
On Friday 14 December 2007, Bill Hoffman wrote:
Rodolfo Schulz de Lima wrote:
I see... after some thought I understood that the user would
(rightfully) expect that call_command would be executed in build time.
What if it he executes something that the generator cannot handle (open
a
On Monday 03 December 2007, Jesse Corrington wrote:
I am going to be working on a new generator for CMake to output Symbian
build files. I am poking around the source a little today, and I have a few
questions. What are the classes I am required to create. Do I need a
cmGlobalGenerator
On Thursday 13 December 2007, Josef Karthauser wrote:
-Original Message-
We do it this way:
cmake -DCMAKE_CXX_COMPILER_WORKS=1 -DCMAKE_C_COMPILER_WORKS=1
-DHAVE_CMAKE_SIZEOF_VOID_P=1 .
That looks like a bad idea to me The void one in particular. You
should
On Wednesday 05 December 2007, Bill Hoffman wrote:
I have a beta release for 2.4.8 ready for cmake. This will be the last
release of the 2.4.X branch. The next release will be 2.6.0. So,
please make sure you test it if you are interested in a 2.4.8. Send any
issues to me or the cmake list.
Alexander Neundorf escreveu:
On Friday 14 December 2007, Bill Hoffman wrote:
That said, an automatic way of running a cmake script at build time as
part of a custom_command might be a good feature.
See bug report #3604 :-)
I think a dig on old bug reports could reveal very interesting
Brandon Van Every escreveu:
not many, and mine was well, then nobody's gonna follow you. I'd like
to see the renegade improvements energy ploughed back into the CMake
community somehow, because Kitware is still clearly the winning team
that people are going to follow. Most of my concerns
61 matches
Mail list logo
