Re: [CMake] Return values from CMake functions?
While not super sexy, you can do what you are looking for with a minor
twist. The following code illustrates it.
function(assertdef VARNAME RESULT_NAME)
if(NOT DEFINED ${VARNAME})
message(SEND_ERROR Error, the variable ${VARNAME} is not defined!)
endif()
set (${RESULT_NAME} ${VARNAME} PARENT_SCOPE)
endfunction()
# comment the next line to see the two different results
set (myvar 1)
assertdef(myvar varname)
if (${varname})
message(${varname} is true)
endif()
With respect to the general question of functions returning values it could
be done but it is a bit of a big change. Functions and commands look the
same (and should act the same IMO) to the people using them. So really we
are talking about commands returning values. This is mostly just a syntax
issue. Right now we have
command(arg arg arg
)
to support return values we need something that could handle
command (arg command2(arg arg) arg arg
)
or in your case
if(assertdef(foo))
or in another case
set(foo get_property(
))
etc. This hits the parser and the argument processing in CMake but I think
it could be done. I guess Im not sure if we *should* do it. Open to
opinions here.
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
[EMAIL PROTECTED]
518 371 3971 (w/f)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Bartlett, Roscoe A
Sent: Thursday, November 20, 2008 11:19 AM
To: cmake@cmake.org
Subject: [CMake] Return values from CMake functions?
Hello,
Has anyone thought about the possibility of adding return values from CMake
functions? This would be a very useful language feature that the Trilinos
CMake files would use everywhere.
Here is an example use case. One problem with CMake is that it has very
loose checking. For example, if I write:
IF (MYVARABLE)
...
ENDIF()
Instead of what I meant:
IF (MYVARIABLE)
...
ENDIF()
then my CMakeLists.txt file will not work correctly. What I have been doing
is to instead write an ASSERT_DEFINED(...) macro and then use it as:
ASSERT_DEFINED(MYVARIABLE)
IF (MYVARIABLE)
...
ENDIF()
Of course the problem with this is that I could misspell one of the uses as:
ASSERT_DEFINED(MYVARIABLE)
IF (MYVARABLE)
...
ENDIF()
and I am back in the same situation. The problem is that I am duplicating
the variable name. This is a fundamental software engineering issue that
needs to be addressed in some way.
What I would like to be able to write is a function like:
FUNCTION(ASSERTDEF VARNAME)
IF(NOT DEFINED ${VARNAME})
MESSAGE(SEND_ERROR Error, the variable ${VARNAME} is not defined!)
ENDIF()
RETURN(${VARNAME})
ENDFUNCTION()
You could then use this function like:
IF (${ASSERTDEF(MYVARIABLE)$)
...
ENDIF()
Then, if I misspelled the variable name as:
IF (${ASSERTDEF(MYVARABLE)}$)
...
ENDIF()
I would get an error message and processing would stop immediately.
Above, I assume that the syntax:
${SOMEFUNCTION(ARGS)}
Is needed to get CMake to expect a return value from the function and then
return it, just like it would return a variables value.
How hard would it be to all return values from CMake functions in this way?
Thanks,
- Ross
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Return values from CMake functions?
True, if you mismatch the typing of varname it fails. At least with this
approach it can be a fairly short variable and not something like
CXX_SHARED_LIBRARY_LINKER_FLAGS_DEBUG which begs to have typos in it :-)
The suggestion I had was to use the ${SOMETHING(...)} syntax to invoke a
function call. So you would have:
I don't think you need the ${} syntax. Such syntax could be used, but just
SOMETHING(...) would work as well. I remembered that the CVS version of
CMake has some parser changes already in it that allow for
if (func())
to be parsed. It is mainly a matter of the argument expansion code being
modified to actually call func when it sees it followed by a pair of parens.
That and a bunch of changes to the signature of commands to allow for return
values/debugging info/etc. That is the bigger task. I'm assuming it would be
zero or more return values like lua, no reason to limit it to just zero or
one like C.
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
[EMAIL PROTECTED]
518 371 3971 (w/f)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Parentheses in conditionals
I just checked in a change for feature request #6191, you can now (in CVS CMake) use parentheses in if and while command conditionals. E.g. if (2 GREATER 1 AND (4 LESS 3 OR 5 LESS 6) AND NOT (7 GREATER 8)) message() endif() evaluation of parenthetical groups has the highest order of precedence. If you bump into any problems with this let me know. Thanks Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 [EMAIL PROTECTED] 518 371 3971 (w/f) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting Makefiles sensitive tonew/deleted files/directories?
Can you do the glob, configure the result out to a file, then INCLUDE
that
file. I believe that will solve the problem. Something like
file(GLOB SRC *.cpp)
configure_file(somefile.in somefile)
include(somefile)
where somefile.in looks like
# list of files as a comment -- ${SRC}
This works because CMake does check (at make time) to see if any
included
file in CMake has changed but is smart in that configure_file only
writes
the file if it has changed. I'm pretty sure something like that will
work.
Thinking about this some more I think you could add a custom target that
does the glob at build time, and stores the results in a file that gets
included by CMake. So what would happen is:
cmake -- files are globbed and used as well as written into a files.last
make -- files are globbed and written into a files.last if different
(which at this point they are not)
joe schmo adds some new files into the tree
make -- files are globbed and written into a files.last if different
(which they will be) the build will probably fail as the makefiles do not
have the new files
make -- detects that files.last is different and reruns cmake producing
valid makefiles with the new source files.
Not a great solution as the build can fail the first time new files are
added but ...meh...really the fix is to have Cmake handle this if it can be
handled without making other builds that do glob for other reasons not slow
down.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting Makefiles sensitive tonew/deleted files/directories?
As Bill reminded me this idea doesn't work, nothing reruns the glob at check
build time. - Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
Can you do the glob, configure the result out to a file, then INCLUDE that
file. I believe that will solve the problem. Something like
file(GLOB SRC *.cpp)
configure_file(somefile.in somefile)
include(somefile)
where somefile.in looks like
# list of files as a comment -- ${SRC}
This works because CMake does check (at make time) to see if any included
file in CMake has changed but is smart in that configure_file only writes
the file if it has changed. I'm pretty sure something like that will work.
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bill Hoffman
Sent: Wednesday, March 19, 2008 10:13 AM
To: Convey Christian J NPRI
Cc: cmake@cmake.org
Subject: Re: [CMake] Getting Makefiles sensitive tonew/deleted
files/directories?
Convey Christian J NPRI wrote:
Many of my CMakeLists.txt files has code like this:
FILE(GLOB SRC *.cpp *.c)
ADD_LIBRARY(my_lib ${SRC})
My users occasionally get tripped up because after someone adds a new
.cpp file, the other users forget to rerun cmake before running
make.
Has anyone considered enhancing CMake so that when the set of source
files picked up by a FILE(GLOB ...) command changes, cmake is
automatically re-run?
Even if a new command had to be added, or a new option to the
FILE(...)
command, that would be fine. But this is probably the main problem I'm
seeing my users encounter with our CMake-based build system. I'd be
very
happy if we could eliminate it.
Really this is not a recommended way of setting up a cmake project. I
suppose this could be done when cmake check build system is done. It
would slow down the cmake check because it would have to do the glob
each time the build system is run. It would not be trivial to
implement. Also, this kind of thing can cause trouble if you put temp
files in your source directory that happen to match. Is it really that
hard to list all the files you want to build?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting Makefiles sensitive tonew/deleted files/directories?
Can you do the glob, configure the result out to a file, then INCLUDE that
file. I believe that will solve the problem. Something like
file(GLOB SRC *.cpp)
configure_file(somefile.in somefile)
include(somefile)
where somefile.in looks like
# list of files as a comment -- ${SRC}
This works because CMake does check (at make time) to see if any included
file in CMake has changed but is smart in that configure_file only writes
the file if it has changed. I'm pretty sure something like that will work.
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bill Hoffman
Sent: Wednesday, March 19, 2008 10:13 AM
To: Convey Christian J NPRI
Cc: cmake@cmake.org
Subject: Re: [CMake] Getting Makefiles sensitive tonew/deleted
files/directories?
Convey Christian J NPRI wrote:
Many of my CMakeLists.txt files has code like this:
FILE(GLOB SRC *.cpp *.c)
ADD_LIBRARY(my_lib ${SRC})
My users occasionally get tripped up because after someone adds a new
.cpp file, the other users forget to rerun cmake before running make.
Has anyone considered enhancing CMake so that when the set of source
files picked up by a FILE(GLOB ...) command changes, cmake is
automatically re-run?
Even if a new command had to be added, or a new option to the FILE(...)
command, that would be fine. But this is probably the main problem I'm
seeing my users encounter with our CMake-based build system. I'd be very
happy if we could eliminate it.
Really this is not a recommended way of setting up a cmake project. I
suppose this could be done when cmake check build system is done. It
would slow down the cmake check because it would have to do the glob
each time the build system is run. It would not be trivial to
implement. Also, this kind of thing can cause trouble if you put temp
files in your source directory that happen to match. Is it really that
hard to list all the files you want to build?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Lua in a nutshell
2.Closing statements need and empty () [at least they don't need to
duplicate the expressions any more].
Technically I believe this is possible. It has been asked for in the past.
Just a change to the yacc IIRC. I tend to not mind () personally.
7.It has no functions (implemented in the script itself I meant) [macros
are
not the same]
2.6 has functions
12.It has no scope.
Well directories have scope and always have, now functions do as well. There
is no midstream push/pop scope ala { } but you can just make a function.
There is also some object scope supported through the use of properties on
targets/source files/directories/tests/etc. But in general there has been a
bad habit of creating a lot of global variables.
16.Least but not least: the language is extensible but not in the user
side.
That is, I cannot *plugin* (entirely at the user side) my own internal
functions even though the underlying system is quite extensible.
You can define your own commands and even override the default commands from
the script level.
You can also use the C plugin API to dynamically compile and load a run time
plugin. We discourage this as it is more prone to errors (user running a
32bit CMake but building a 64 bit executable tries to dynamically load a 64
bit module into a running 32 bit cmake, etc, etc) This could be fixed by
running the plugin in a separate process etc but I'm just not sure we really
want to expose/encourage that low level of an API.
Good points though (including the ones I did not touch on) and I do agree
with them. Many of them we have discussed around here in the past.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake and Lua
In principle CMake implements two thing, - a scripting language, - and a make/build-file generator. As I understand it, these two things are currently mixed up in CMakeLib: all commands parse the arguments (scripting functionality) and then call the generator function with the found arguments, for instance this-Makefile-AddSubDirectory(.. This makes it hard to introduce a new scripting language, if it should not only be a wrapper of the current cmake commands. Isn't this your ansatz in your Lua experiment? http://www.cmake.org/Wiki/CMake:Experiments_With_Lua http://www.assembla.com/wiki/show/CMakeLua I would choose a different way: First I would split the current CMakeLib into two libs, one which implements the macro language, and the other which implements the generator stuff only, nothing knowing about any scripting/macro language. In VTK and ITK we did design a language independent toolkit and wrapped it into Tcl, Python, Java etc so we have done that and have a good feel for it. But for CMake I do not think it is a good idea for a couple reasons. One is fragmentation of the community/support. The other is that a non-trivial portion of CMake is written in the scripting language ala the Modules directory. So supporting multiple languages becomes problematic. Most languages are not designed to mix with other languages. I doubt you can mix python and Lua and expect them to be able to access each other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed CMakeScript/Lua variables by itself is already a bit of an issue to providing a Lua binding much less adding other languages on top of that. Hopefully that makes some sense :) Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake and Lua
I'm even more convinced that having only limited programming functionality available in build files is a good thing. While the cmake language may not be beautiful, it works, and the users (developers) are not supposed to write programs with it. OMG flame war Bring it! :) Seriously though, it probably depends on what you mean by write programs and limited programming functionality I think in the end you need a language you *could* at least write bad programs in :). Case in point the CMake language originally did not include many of the programming constructs it now has; macros, foreach, while, functions, etc. Heck a very basic version of the if statement was not added until a full six months after development was rolling along. It was intended to be pretty much declarative. But these features were all added because big projects need more than a declarative format. They need conditionals. And the really big projects need other constructs for code management. For example: VTK has around 20,000 lines of CMake code to build it (which is a bit absurd but...). When you get to 20,000 lines you need some form of structure to it, code reuse, etc, otherwise it just becomes a mess. Which is why CMake has include, macro, foreach etc. which are all staples of a programming language. I do get your point that people should not *have* to program to do common tasks. Some other build systems seem to rely on the user to do far too much. The build system should include support for all common tasks at a high level as macros or commands etc. But I think you still need programming power for the corner cases large projects bump into. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest - how to set environment
Really we need to implement set_property(TEST testname ENVIRONMENT bah=foo;fu=bar;display=:0.0) and have ctest honor it which really should be pretty easy just a matter of coding it up. The property stuff is already there and gets passed to the test in ctest. CTest just has to look for that property and do some setenv calls. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:cmake- [EMAIL PROTECTED] On Behalf Of Bill Hoffman Sent: Wednesday, February 20, 2008 2:21 PM To: David Cole Cc: cmake@cmake.org Subject: Re: [CMake] ctest - how to set environment David Cole wrote: As I wrote in my first mail, I'm failed using CTEST_ENVIRONMENT inside a CMakeLists.txt. I have not tried this in a special ctest script because I'm searching for lean solution. Which means write a 'CMakeList.txt' once, run 'cmake' once and be able to run 'make test' for every change on my software. My problem is: there is make test target, I want to use it, but all tests fail because of the missing environment variables. Maintaining a ctest script besides the CMakeLists.txt is too much effort for my current purpose. As described in http://www.cmake.org/Wiki/CMake_Testing_With_CTest Simple Testing (The easiest way to create CTest input files is using CMake.), I just want to generate / call the tests within the build process (with the existing test target), and not define/maintain a parallel build/test process. So, this whole issue has to do with cmake time vs build time. As long as cmake is a running process then you can set env vars. When that process is over then the env is gone. One thing you could do is have your test be run by a cmake script. So, you would wrap your tests in some cmake script that set the environment variable. The scripts would use execute_process to run the tests, and -D options to the script to pass options to your test. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Wee question about CMake developer etiquette
Of course, this doesn't identifies the project leaders, but at least gives an idea of who has typed enough lines of code to earn the right to speak for a project. Actually it identifies who committed enough lines ... which is not quite the same as writing them. For CMake the Utilities directories have a lot of code but we did not write most of it. But I'll agree the general idea holds ;) Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: function and raise_scope commands (+ unset bug)
Would
RAISE_SCOPE(var1 var2 ... varN)
be better ?
Why was the syntax changed from that to
RAISE_SCOPE(varname value) ?
(which was basically a set() and that's why converted to
set(... PARENT_SCOPE) )
The old syntax of raise scope often required that you first set the value of
the variable locally then raise it. This was prone to cause variable
collision. For example...
function (foo var)
set (${var} wasabi}
raise_scope(${var})
endfunction(foo)
foo(var)
message (var should be set to wasabi but is set to: ${var})
results in var being undefined when it should be set to wasabi. Using the
new syntax...
function (foo var)
set (${var} wasabi PARENT_SCOPE}
endfunction(foo)
foo(var)
message (var should be set to wasabi but is set to: ${var})
produces the correct result.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: function and raise_scope commands (+ unset bug)
FUNCTION(SET_VAR1 varname)
SET(${varname} There's science to do PARENT_SCOPE)
ENDFUNCTION(SET_VAR1)
FUNCTION(SET_VAR2 varname)
SET_VAR1(${varname})
ENDFUNCTION(SET_VAR2)
SET_VAR2(foo)
MESSAGE(${foo})
Obviously foo is not set, since it is now set in SET_VAR2 scope. Bummer.
So now I have to do things like this:
FUNCTION(SET_VAR2 varname)
SET_VAR1(varname_proxy)
SET(${varname} ${varname_proxy} PARENT_SCOPE)
ENDFUNCTION(SET_VAR2)
Which I guess I could live with
And you should live with that. And like it dang it! :) A function should be
clear on what variables it is modifying in the parent scope without having
to look at every function it in turn calls. This does make for more code,
but the resulting code is more self documenting. Otherwise if SET_VAR1 were
in a different file, just by looking at SET_VAR2 you would not know it is
returning anything.
But wait, it gets weird. In my macros it's not unusual that I
*unset* variables (yes, I do), using SET(var). I was wondering if
that would work. It kinda does, but not quite:
FUNCTION(SET_VAR1 varname)
SET(${varname} PARENT_SCOPE)
ENDFUNCTION(SET_VAR1)
FUNCTION(SET_VAR2 varname)
SET_VAR1(varname_proxy)
SET(${varname} ${varname_proxy} PARENT_SCOPE)
ENDFUNCTION(SET_VAR2)
SET_VAR2(foo)
IF(DEFINED foo)
MESSAGE(foo is defined)
ELSE(DEFINED foo)
MESSAGE(foo is NOT defined)
ENDIF(DEFINED foo)
This will display that foo is NOT defined, even though it should be
defined, if you unroll all the functions into a simple script. Note
that replacing SET(${varname} PARENT_SCOPE) by SET(${varname}
PARENT_SCOPE) will also display that foo is not defined (which was
the expected behavior). Also note that removing the quote around
${varname_proxy} doesn't make any difference here.
Sounds like a bug, set should work the same regardless of scope. Maybe the
fix is that the remove command needs a parent_scope argument as well? So
remove removes and set will set even if it is to an empty string. Sound
right to you Alex?
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] 4th Edition CMake book now in stock
Does the new edition of the book talk about functions, return, break, raise_scope, etc? Only on one the one page errata sheet that comes with it. The main additions are CPack, cross compiling, a couple more steps in the tutorials, and any updates to bring the book up to the state of CMake CVS as of a couple months ago. FWIW: raise_scope no longer exists, the set command now has this functionality using the PARENT_SCOPE modifier. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] 4th Edition CMake book now in stock
This edition of the book is written around 2.6 isn't it? What does this mean (if anything) about the coming release of 2.6? It means 2.6 should go to beta as soon as we possibly can get it there :) We wanted 2.6 to be out when the books arrived. It is close. We just want to make sure the key features that impact scripts are there in 2.6 when it gets released (like functions return break etc). We are very close. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] 4th Edition CMake book now in stock
Kitware has no plans to release an electronic version of the CMake book at this time. Kitware sells the ITK book and also makes it available for free as a pdf. So we do have a track record and real multi-year data concerning making a technical book available in two different mediums and we have some idea of how it impacts the viablility of a book. We have not tried releasing it as a copy protected pdf but many of us are not huge fans of copy protection so, meh. Quite simply it is not financially viable for CMake at this point. Perhaps once CMake grows another factor of four in market penetration it will be viable. And on that financial note I do want to say a big thank you to the folks who put their money into making CMake as viable and beneficial as it is: -- The National Library of Medicine http://www.nlm.nih.gov/ and the other sponsors of the ITK project http://www.itk.org/ -- The National Alliance for Medical Image Computing http://www.na-mic.org/ -- Sandia National Labs http://sandia.gov/ -- The Advanced Computing Lab at LANL http://www.acl.lanl.gov/ -- Everyone who has purchased a CMake book :) And a big thanks to those who put their time into helping debug problems with CMake, or answering other people's questions, or teaching a noob coworker how to get started, or writing a new module, etc. Without all of you CMake would not survive. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] return and break commands
This is the commit that has the changes in it. Lots of little changes mainly. http://www.cmake.org/Testing/Sites/DASH2.kitware/Win32-vs70/20080123-1550-Co ntinuous/Update.html Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 I don't mind porting the bits myself, but as it's cvs it's a bit hard to determine what changes are required :). (No atomic commit numbers!) I don't suppose you have a commit email or log somewhere which would tell me all the version numbers of that change do you? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] return and break commands
What would be useful, would be to be able to interrupt the current CMakeLists file, from within a macro. We initially implemented it that way but due to some obscure parts of the US export control laws we realized we would never be able to distribute it. OK, I just made that up, but I'm sure most of you believed me, well ... maybe not that many :). Seriously though, for macros what you are looking for is the current behavior I believe. Consider a macro like an inline expansion. A return in a macro is the same as a return in the CMakeLists file. Functions though are different and have scope etc. Hope that helps. - Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] return and break commands
It would not be that hard to port it, but...I'm pretty sure we are done with the 2.4 branch. 2.4.8 is probably the last of the 2.4 releases. We are (and have been) gearing up for the 2.6 release which I hope we will get into beta in a few weeks. - Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: Josef Karthauser [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 3:11 AM To: Ken Martin; cmake@cmake.org Subject: RE: [CMake] return and break commands How easy would it be to port this functionality to 2.4.x? Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Martin Sent: 23 January 2008 15:56 To: cmake@cmake.org Subject: [CMake] return and break commands I just checked into CVS return and break commands for CMake. They work pretty much how you would expect the usual C return and break commands to work. A couple quick notes: 1) Macros are like cpp macros (not functions), a return in a macro is no different than an inline return. 2) return from a directory/file (as opposed to a function) will stop processing that CMakeLists file and return control to the parent (whoever called add_subdirectory) if there is a parent. 3) break works on foreach and while loops. A break inside an if/else clause breaks you out of the enclosing foreach or while loop just like C. The same idea holds for return statements inside an if/else/foreach/while, they return you out of the current function or directory. 4) return invoked from an included file should stop processing the current file and take you back to the point of the include command. (forgot to add a test for this one, but really, what are the odds untested cases would have a bug in them :) *kidding* 5) basically these commands should do something fairly intuitive Give me a holler if there are problems. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: function and raise_scope commands
Yes, and I'll also remove raise_scope() then. Ok ? Yuppers - Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: function and raise_scope commands
I think the patch to the set command is probably the best bet. Raise_scope
could be made to do the same thing but honestly the changes to set are
pretty simple and that clears up some confusion about raise scope not
setting the local variable and not actually raising the local variable's
setting. Aka raise_scope changed over time and set is now a better fit ffor
what is being done. Can you check that in Alex and mod the function test to
use it?
Thanks
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: Alexander Neundorf [mailto:[EMAIL PROTECTED]
Sent: Friday, January 18, 2008 12:54 PM
To: cmake@cmake.org
Cc: [EMAIL PROTECTED]
Subject: Re: [CMake] Re: function and raise_scope commands
On Friday 18 January 2008, Rodolfo Schulz de Lima wrote:
Miguel A. Figueroa-Villanueva wrote:
Again, I think this behaviour is a quite unintuitive and should be
well documented, at least.
I shall add that at first I expected 'raise_scope' to work like 'set'
when the parameter value is a list. But, for instance:
set(mylist item1 item2 item3)
set(var1 ${mylist})
raise_scope(var2 ${mylist})
in this example, var1 gets the 3 items, whereas var2 gets only 'item1'.
That's odd and also counterintuitive.
How about the attached patch ?
It adds an argument PARENT_SCOPE to the SET() command, which then replaces
the
RAISE_SCOPE() command:
set(foo a b c PARENT_SCOPE)
I'm not sure it is a good idea that this also propagates to the parent
directory. What is a use case for this ?
Bye
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] function and raise_scope commands
1. CMake crashes if I use the same variable name as the argument and
raise the scope later. That is, for the following function:
function(track_find_variable cache_variable is_changed)
raise_scope(${is_changed})
endfunction(track_find_variable)
I can't call it like:
track_find_variable(testvar is_changed) # I had to mangle is_changed
above, but that's ok
I think it shouldn't crash. If its too much effort to have cmake
support this, then I don't think it is worth it... just having a note
that the argument can't be used as a variable name in the help and
maybe try to detect the case and signal an error...
This still doesn't work. I don't know if you have done anything for this.
Actually the code above works for me. If you add a set command of the
variable before the raise scope then I see the problem you describe. The
variable that has the name of the variable in it (is_changed) gets
overridden because it has the same name as its value.
Specifically
Variable value
is_changed is_changed
set(${is_changed} some_result)
is_changed some_result
raise_scope(${is_changed})
well this last line becomes raise_scope(some_result) and since there is no
local variable named some_result it yerks. I have fixed the crash and it now
prints a nice warning message (on my local copy of cmake, not checked in
yet) but I'm not sure that is all the solution. I think a safer fix may be
to change the raise scope command to look like the following:
raise_scope(var_name value var_name value ...)
with a convention that you do not set variables that are to be returned (aka
passed by reference). In this case that would be is_changed. You leave
is_changed alone and only use it in the raise scope command. So the
resulting code would look like.
function(track_find_variable cache_variable is_changed)
set(changed some_result)
raise_scope(${is_changed} ${changed})
endfunction(track_find_variable)
which is safer. But I am still want to think about it a bit before I commit
the change.
3. I'm having another issue. If you pass a variable to a function that
hasn't been defined previously and that isn't defined in the function
either, then it crashes when you do a raise_scope on it.
For instance, if you have the following function:
Pretty sure I have fixed this on my local copy of the code. I'll check it in
with the above fixes in a few days (still on vacation for a few more days)
Thanks
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] function and raise_scope commands
Thanks for the information. Both these issues I suspect are fairly simple
bugs and will be fixed.
Thanks
Ken
1. CMake crashes if I use the same variable name as the argument and
raise the scope later. That is, for the following function:
function(track_find_variable cache_variable is_changed)
raise_scope(${is_changed})
endfunction(track_find_variable)
I can't call it like:
track_find_variable(testvar is_changed) # I had to mangle is_changed
above, but that's ok
I think it shouldn't crash. If its too much effort to have cmake
support this, then I don't think it is worth it... just having a note
that the argument can't be used as a variable name in the help and
maybe try to detect the case and signal an error...
2. Given the new scope contexts, when I call the following function:
function(tester)
message(STATUS ${CMAKE_CURRENT_LIST_FILE})
endfunction(tester)
tester() prints what it should:
D:/builds/temp/testLatexModule/CMakeLists.txt
However, if I put it in a cmake_utils.cmake file and call
include(cmake_utils):
tester() prints garbage... somehow it gets corrupted. For example, in
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] function and raise_scope commands
I checked into CVS two new commands; function and raise_scope (well three
commands if you count endfunction)
The function command is very much like the macro command but it creates a
new scope for variables and its arguments are variables not string
replacements. Recall that a cmake macro is like a cpp macro and simply does
string replacements for its arguments. The new variable scope of a function
is the same as the new variable scope of a sub directory. Specifically:
1. It inherits all of the values from the parent scope at the time the new
scope is created
2. Any changes or new variables are localized to the new scope and do not
change the parent scope
3. set CACHE can be used to set variables in the cache regardless of scope
I made functions work like new directories so that CMake would have one
consistent notion of how a new scope works. function and add_subdirectory
(and subdirs for that matter) both create new scopes and they do it exactly
the same way. I also added a command called raise_scope. This command will
take a list of local variables and push their values up to the parent scope.
This command can be used in both subdirectories and functions. For Tcl folks
this is much like the upvar command. Consider a toy example.
# test recursion and return via raise_scope
function (factorial argument result)
if (argument LESS 2)
set (${result} 1)
else (argument LESS 2)
math (EXPR temp ${argument} - 1)
factorial (${temp} tresult)
math (EXPR ${result} ${argument}*${tresult})
endif (argument LESS 2)
raise_scope (${result})
endfunction (factorial)
factorial (5 fresult)
if (fresult EQUAL 120)
message (factorial worked)
else (fresult EQUAL 120)
message (factorial, computed ${fresult} instead of 120)
endif (fresult EQUAL 120)
It looks much like a macro but note that you can do if (argument ...
because argument is a real variable not just a string replacement. With a
macro this would not work. Next we do some recursion and finally at the end
we call raise_scope to return the value to the caller. We allow the user to
pass in the name of the result variable and use raise_scope to set that
variable, in the caller's scope, to the resulting value. ARGV, ARGC, ARGN,
and ARGV0, ARGV1, ... are all defined as well to support variable argument
lists. Note that in this example argument, result, temp, and tresult are all
local variables and do not impact the parent scope, nor do their values in
recursive calls to factorial impact the values in the parent calls.
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Using Macro function like
C2ADA(${LIST_OF_FILES} ADS)
You want
C2ASA(${LIST_OF_FILES} ADS)
then your macro will receive two arguments, the first of which is a list.
Teh in yoru macro you can use foreach to traverse the first argument. VTK
uses this approach for the wrap tcl macro.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. Yup, just a quick zip of what is on my disc which is windows hence the CR/LF etc. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. Yeh. My bad. I either need to remove it from the bootstrap or support it in the bootstrap then that error should go away. For the regular cmake build (aka post bootstrap/windows) it is in the tree so it is easy. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. The LuaFunction is an ivar and can be overridden in subclasses. This is how I made get_property a function that returns a value. See cmGetProperty.cxx for an example of this. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake with Lua Experiment
Just heading down this path as an experiment to get a better feel for it. Posted a snapshot of the source code on the Wiki http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The biggest issues I see are 1) keeping two languages around sounds like more work and who needs more work 2) variables in lua are not variables in CMake and vice versa. The cm_configure_file command only configures cmake variables, this could be a good thing in one sense :) Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] lexical scoping
Variables can be a PITA :) They have unusual scoping, mixed documentation, etc. In CVS there have been some changes. We have extended the concept of properties which are scoped to an object (source file, target, directory, global, test, for example) and are documented, can be inherited, and can be tested to verify they are documented. This is nice and meets some needs of CMake. But ... there are still variables. Recently Bill and I have started documenting variables in the source code (cmake --help-variables works) such that you can get documentation on supported variables in cmake. These documented variables are the ones we will try to keep backwards compatible (tm), all others are up in the air. But to the question at hand...adding scope to variables. Variables have scope right now of 1) the CMakeListfile they are defined in 2) any included files that are included after the variable is set 3) and subdirectories of the directory they were defined in and processed after the setting of the variable 4) they can be access globally using get_directory_property and specifying the directory etc the macro command is like a cpp macro so scoping does not make a lot of sense for it. What would/could make sense is a function command that creates a function. (think of the difference in a macro versus a function in c, macros have no inherent scope they are just string replacements, functions do have scope built in). With a function command we could probably figure out some way to create variables that are scoped to the function only. Most of the places we are using macros really could/should be functions. My main question would be if we had a function, how would you want variables handled. 1) all set commands create local variables to the function (a mess for functions that do an include of other cmake code) 2) a special set command or signature that creates a local variable scoped to the current function 3) a mode to switch the behavior of set (yuck) 4) something else Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KSpam Sent: Friday, November 02, 2007 1:32 PM To: cmake@cmake.org Subject: Re: [CMake] lexical scoping On Friday 02 November 2007 09:54:51 Brandon Van Every wrote: Is it feasible to modify the CMake language to have lexical scoping? I agree. The lack of variable scoping is currently my biggest annoyance with custom macros. Additionally, I believe that custom macros are pretty much required for any mid to large scale project. Life in the CMake scripting language would be so much nicer if we could scope variables at the macro and/or file level. Justin ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Cmake variable indicating ctest dashboard build (likeDART_ROOT)
My Dart knowledge is a bit rusty, but I believe that DART_ROOT is set regardless of if you are doing a build for a dashboard. Specifically it is set by anything that includes Dart.cmake, was able to find dart, and has BUILD_TESTING turned on (it is on by default). So the value will not change between doing a manual build or one that is driven by the dashboard process from what I can see. Now if only your dashboard machines have Dart installed then it would effectively work since only on them would DART_ROOT be set. In that case it is really more a test of if Dart is installed. It sounds like you want to change the build (well configuration step really) based on if it is a dashboard build or not. The general way to do that is by setting the initial cache in the CTest script as you noted in your example. Hopefully that makes sense. Thanks Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wheeler, Frederick W (GE, Research) Sent: Tuesday, July 31, 2007 12:53 PM To: cmake@cmake.org Subject: [CMake] Cmake variable indicating ctest dashboard build (likeDART_ROOT) Cmake list: In the VXL project we use the cmake variable DART_ROOT to determine whether the build is being done for the dashboard. But if ctest is used, DART_ROOT is not set. Is there a different variable that should be used for this purpose that works for both the old tcl-Dart1 and new ctest? Here is a typical current VXL use of DART_ROOT ... # Default the dashboard builds to YES so that # we have some clients that try to compile vgui IF( DART_ROOT ) OPTION( BUILD_VGUI Build VGUI YES ) ELSE( DART_ROOT ) OPTION( BUILD_VGUI Build VGUI NO ) ENDIF( DART_ROOT ) . and I really just want to do the following in the right way ... # Option to specify whether this is a build for the dashboard # - If Dart (TCL) is being used for the dashboard build, DART_ROOT #will be set. # - If CTest is being used for a dashboard build, set #BUILD_FOR_VXL_DASHBOARD to YES using SET (CTEST_INITIAL_CACHE ...) #in the CTest script (until we find a better method right here). IF( DART_ROOT ) OPTION( BUILD_FOR_VXL_DASHBOARD Is this a build for the dashboard? YES ) ELSE( DART_ROOT ) OPTION( BUILD_FOR_VXL_DASHBOARD Is this a build for the dashboard? NO ) ENDIF( DART_ROOT ) Thanks, Fred ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Next Edition of the CMake Book
We will be beginning work on the next edition of the CMake book soon. It will probably become available late this year. We will be adding a sections on Cpack and cross compiling in this edition. If you have any suggestested changes or corrections to its contents please send them my way. Thanks Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Progress above 100% when making chicken-2.6
CMake can get above 100% (or other screwy situations) in a couple odd cases, such as killing an install done as root half way through, and then doing a build as non-root. Basically it uses some files for tracking progress and if they get written by root and left there (like in an aborted install) then the user account cannot clean them out. Another case is if you do two builds in the same tree from different processes (not a parallel build using -j 2, but two different make invocations in the same tree) This can also happen if you invoke a make in the tree as part of a custom rule within the build. e.g. you do a recusrive make on your own as part of a custom rule. They are odd cases but they could happen. I'll try adding some more error checking for those cases at some point. But more specifically for your case, what target are you making? The all target from the top level? Is there a /CMakeFIles/Progress directory still lying around? Are you running just one make? Does chicken do a recusrise make/build as part of a custom command (e.g. invoke make directly as part of a custom command?) Thanks Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clark J. Wang Sent: Wednesday, June 27, 2007 9:59 PM To: CMake Mailing List Subject: [CMake] Progress above 100% when making chicken-2.6 I downloaded chicken-2.6 from http://www.call-with-current-continuation.org/index.html and compiled it with CMake-2.4.6. When making, the progress percentage showed more than 100%: ... ... [ 96%] Building C object CMakeFiles/libuchicken.dir/runtime.o [ 98%] Building C object CMakeFiles/libuchicken.dir/match.o [ 98%] Building C object CMakeFiles/libuchicken.dir/profiler.o [ 98%] Building C object CMakeFiles/libuchicken.dir/scheduler.o [100%] Building C object CMakeFiles/libuchicken.dir/stub.o [100%] Building C object CMakeFiles/libuchicken.dir/ueval.o [100%] Building C object CMakeFiles/libuchicken.dir/uextras.o [100%] Building C object CMakeFiles/libuchicken.dir/ulibrary.o [101%] Building C object CMakeFiles/libuchicken.dir/ulolevel.o [101%] Building C object CMakeFiles/libuchicken.dir/uposixunix.o /root/tmp/chicken-2.6/cmakebuild/uposixunix.c: In function 'f_5645': /root/tmp/chicken- 2.6/cmakebuild/uposixunix.c:3591: warning: implicit declaration of function 'getpgid' [101%] Building C object CMakeFiles/libuchicken.dir/uregex.o [103%] Building C object CMakeFiles/libuchicken.dir/usrfi-1.o [103%] Building C object CMakeFiles/libuchicken.dir/usrfi- 4.o [103%] Building C object CMakeFiles/libuchicken.dir/usrfi-13.o [104%] Building C object CMakeFiles/libuchicken.dir/usrfi-14.o [104%] Building C object CMakeFiles/libuchicken.dir/usrfi-18.o [104%] Building C object CMakeFiles/libuchicken.dir/utcp.o [106%] Building C object CMakeFiles/libuchicken.dir/uutils.o Linking C shared library libuchicken.so [113%] Built target libuchicken ... ... Interesting :-) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Possible bug in cmake version 2.4-patch 6 with macroargument testing
A macro in cmake is a bit like a cpp macro. It is a string replacement
operation that replaces ${varname} with the actual argument to the macro.
Then it executes the commands. At one point we considered (and tried) making
the macro arguments be variables but there are existing projects out there
that rely on a macro being a macro, not a function. i.e. they rely on the
string replacement behavior as opposed to variable behavior. So what that
means is that in the example below:
MACRO (MYMACRO boolarg)
MESSAGE (MYMACRO(${boolarg}))
IF (boolarg)
After string replacement of ${boolarg} with TRUE looks like
MACRO (MYMACRO boolarg)
MESSAGE (MYMACRO(TRUE))
IF (boolarg)
The IF statement tests to see if there is a variable defined named boolarg
and there is not (there have been no SETS done on boolarg) and so the
conditional is false. So the trick is that macros need to be thought of as
only doing string replacements on ${something}.
Hope that helps
Ken
# Possible bug in cmake version 2.4-patch 6 where macro arguments
# don't test correctly. When run this produces:
#
# mytrue=TRUE [msg1]
# MYMACRO(TRUE)
# boolarg=TRUE [False path]
# _var=TRUE [True path]
#
MACRO (MYMACRO boolarg)
MESSAGE (MYMACRO(${boolarg}))
IF (boolarg)
MESSAGE (boolarg=${boolarg} [True path])
ELSE (boolarg)
MESSAGE (boolarg=${boolarg} [False path])
ENDIF (boolarg)
SET (_var ${boolarg})
IF (_var)
MESSAGE (_var=${_var} [True path])
ELSE (_var)
MESSAGE (_var=${_var} [False path])
ENDIF (_var)
ENDMACRO (MYMACRO boolarg)
SET (mytrue TRUE)
IF (mytrue)
MESSAGE (mytrue=${mytrue} [msg1])
ELSE (mytrue)
MESSAGE (mytrue=${mytrue} [msg2])
ENDIF (mytrue)
MYMACRO(${mytrue})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Bug in ADD_LIBRARY (again?)
The fix to ADD_LIBRARY is in CVS and has not been put into a patch yet. It should make it into 2.4.7. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guilherme Balena Versiani Sent: Thursday, May 17, 2007 11:28 AM To: cmake@cmake.org Subject: [CMake] Bug in ADD_LIBRARY (again?) Hello, The ADD_LIBRARY does not understand EXCLUDE_FROM_ALL in CMake version 2.4 patch 6. I found a message from Ken Martin dated from Jan/4/2007 saying Yup, I'll check in a fix for it. For which version did this fix go? Or, maybe, are there no available fixed release yet? Regards, Guilherme Balena Versiani. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Using ADD_CUSTOM_COMMAND to generate sources...
Well CMake does not /really/ know about the dependency :) Because the
dependency is done through #include in the source code it is not known at
CMake Configure/Generate time. Dependency analysis of source code is done at
build time. For make based builds CMake does this during the build process
(because someone has to) and stores the results. The reason this is delayed
until build time is that the generated source code and possibly the
executables that run to generate it have to be generated before we can
inspect them for dependencies etc.
The typical way to setup dependencies on generated files is by adding them
(the generated files) to the target, for example:
add_library(libname src1.cxx generated1.h generated1.cxx generated2.h
generated3.h)
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Woehlke
Sent: Tuesday, May 15, 2007 11:46 AM
To: cmake@cmake.org
Subject: [CMake] Using ADD_CUSTOM_COMMAND to generate sources...
Ok... so I see that ADD_CUSTOM_COMMAND is silently ignored if no targets
depend on the OUTPUT. What is strange is that the output is #include'd
from one of my source files, and I can see from looking at the generated
CMakeFiles/mytarget.dir/CXX.includecache that cmake /does/ know about
the dependency. So why do I still have to explicitly tell CMake about
the dependency? (This occurs even if the file is output to the source
directory, i.e. the full path matches what is in the CXX.includecache.)
Also, what is the correct way to set up the dependency? I am using:
set_source_files_properties(main.cpp PROPERTIES OBJECT_DEPENDS
${objects_def})
...but I seem to recall someone saying that this is deprecated?
--
Matthew
People say I'm going insane. I say, what do you mean, 'going'?.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] getting values from subdirs
I believe the following will work. In the top CMakeLists file...
set(myvar initial-value CACHE INTERNAL stored subdir values)
add_subdirectory(subdir)
message(${myvar})
Then in subdir
set(myvar ${myvar} ${other-values-from-this-subdir} CACHE INTERNAL stored
subdir values)
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luigi
Calori
Sent: Thursday, March 15, 2007 12:06 PM
To: cmake@cmake.org
Subject: [CMake] getting values from subdirs
I would like to being able to collect a list of values from a macro that
get called from several subdirs
The obvious solutions to init it into the main CMakeLists and update
whithin the macro does not work as (probably) the init inside the main
CmakeLists get executed
anyway for each subdir
If declare it CACH INTERNAL and I do no init, it get updated but retain
values on different CMake runs any thougt?
A possible solution is to write a filebut it does not seem much elegant
Thanks anyway for the help
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] getting values from subdirs
Add a second set call after the first one in the top level CMakeLists.txt
file. That will clear the local definition such that the toplevel CMakeLists
will get the cache definition. For example...
# initialize the cachwe value
set(myvar easterbunny CACHE INTERNAL stored subdir values)
# clear the local definition
set(myvar)
# let the subdir add to the cache
add_subdirectory(subdir)
# display the result
message(${myvar})
it is a little odd but it should work for you. Another way to do this is
with GET_DIRECTORY_PROPERTIES to get the value of the variable from the
subdirs.
Thanks
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: Luigi Calori [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 12:36 PM
To: Ken Martin; cmake@cmake.org
Subject: Re: [CMake] getting values from subdirs
Ken Martin wrote:
I believe the following will work. In the top CMakeLists file...
set(myvar initial-value CACHE INTERNAL stored subdir values)
add_subdirectory(subdir)
message(${myvar})
Then in subdir
set(myvar ${myvar} ${other-values-from-this-subdir} CACHE INTERNAL stored
subdir values)
Ken
I' v etried... but this don' t work:
i have
set(myvar initial-value CACHE INTERNAL stored subdir values)
add_subdirectory(subdir1)
add_subdirectory(subdir2)
add_subdirectory(subdir3)
message(${myvar})
and seem that the init code in the main get galled before each subdir (this
is a known issue)
I was searching for a workaround...
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luigi
Calori
Sent: Thursday, March 15, 2007 12:06 PM
To: cmake@cmake.org
Subject: [CMake] getting values from subdirs
I would like to being able to collect a list of values from a macro that
get called from several subdirs
The obvious solutions to init it into the main CMakeLists and update
whithin the macro does not work as (probably) the init inside the main
CmakeLists get executed
anyway for each subdir
If declare it CACH INTERNAL and I do no init, it get updated but retain
values on different CMake runs any thougt?
A possible solution is to write a filebut it does not seem much elegant
Thanks anyway for the help
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Progress report
It can go above 100% if you are using an old version of CMake (2.4.3 maybe or older) or if you have multiple makes running at the same time. (not make -j that is OK, but make foo in one shell while you do make bar in another shell where foo and bar are in the same Makefile) This can also happen I believe if you invoke a make in the same tree as part of a custom command within a current make. They are pretty odd cases. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Felix Winkelmann Sent: Friday, February 23, 2007 8:07 AM To: cmake@cmake.org Subject: [CMake] Progress report Hi! Just a tiny, trvial thing... I have the problem that the progress report shows me something long 120% when finished. The relevant CMakeLists.txt is here: http://galinha.ucpel.tche.br/chicken/CMakeLists.txt This behaviour appears to exist on all platforms that I know of (Linux, Windows, OS X), and I'm not sure how to get more details. How does the progress report mechanism work? cheers, felix ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Test sources
We have a test for CREATE_TEST_SOURCELIST in CMake/Tests/TestDriver and it does not use a full path to the tests and it is passing on the dashboard. Perhaps you specified the path to the test source files as a full absolute path? Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Fleury Sent: Sunday, February 18, 2007 6:18 PM To: cmake@cmake.org Subject: [CMake] Test sources Hi CMakers, I am trying to use the CREATE_TEST_SOURCELIST approach to test some existing CppUnit tests. My plan was to have the functions that CTest expects ( the foo(int,char**) for test in file 'foo.cpp' ) be generated, each of them calling the suite from the CppUnit (basically testing a complete class). I have noticed that, contrary to the documentation (online, man page and the book) the function that needs to be present is not 'foo()' for file foo.cpp, but something like '_full_absolute_path_to_my_project_test_foo(int, char**)'. Does CREATE_TEST_SOURCELIST rewrite all test source and replace the expected function with a unique one ? Has anybody any experience in using CppUnit with CMake ? --paf ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Writing a Code Warrior Generator
We did try this once and as Bill said the challenge in the end was that IIRC Code Warrior did not have an easy way to launch compiles from the command line (as used by try_compile etc). I think folks were talking about using some Apple Script to drive it or something like that to work around this but it sounded a tad nasty. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Hoffman Sent: Monday, February 12, 2007 1:20 PM To: Nicolas Debeljak Cc: cmake@cmake.org Subject: Re: [CMake] Writing a Code Warrior Generator Nicolas Debeljak wrote: Hi, I'd like to make a project generator for Code Warrior and more precisely for the xml export format. I've already read the source code of the Visual Studio 7 Generator in order to do something similar but it seems to be very complex (I don't have enough time to understand the code and to adapt it entirely). Do you think it is possible to convert the Visual Studio 7 Generator into a Code Warrior generator just by adapting the vcproj file writing functions ? No, I would start from scratch. However, I think we tried this once and gave up. The IDE has to support command line builds and custom commands or it will not be powerful enough to pass all the CMake tests. I seem to remember not being able to get it working. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Strange problem with parsing variables
Here is the original thread - Ken
http://public.kitware.com/pipermail/cmake/2006-December/012257.html
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: wedekind [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 06, 2007 10:45 AM
To: Ken Martin; cmake@cmake.org
Subject: AW: [CMake] Strange problem with parsing variables
Hi Ken,
thanks for your reply. Though I'm reading this list quite regularly I have
missed this fix :(
Cheers
Marco
-Ursprüngliche Nachricht-
Von: Ken Martin [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 6. Februar 2007 16:42
An: 'wedekind'; cmake@cmake.org
Betreff: RE: [CMake] Strange problem with parsing variables
This was fixed in CVS CMake a couple weeks ago. I sent out an email
describing the issue to the list in response to a similar (or the same)
problem.
Thanks
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
wedekind
Sent: Tuesday, February 06, 2007 9:08 AM
To: cmake@cmake.org
Subject: AW: [CMake] Strange problem with parsing variables
Hello all,
I just want to revive my topic from two weeks ago. Please have a look at
the mail below. Can you reproduce this behaviour? What's the reason behind
it or is it a bug?
Cheers
Marco
-Ursprüngliche Nachricht-
Von: wedekind [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 26. Januar 2007 17:02
An: 'cmake@cmake.org'
Betreff: [CMake] Strange problem with parsing variables
Hello all,
I've encountered a strange parsing problem with a 2-month old checkout
from
CMake's cvs repository. Please have a look at the following sample
CMakeLists.txt:
SET(SOME_VAR 1)
IF(SOME_VAR)
MESSAGE(SOME_VAR is set to true)
ENDIF(SOME_VAR)
IF(NOT SOME_VAR)
SET(SOME_OTHER_VAR some_value)
MESSAGE(SOME_VAR set to false)
IF(some_value STREQUAL ${SOME_OTHER_VAR})
MESSAGE(SOME_OTHER_VAR is set to some_value)
ENDIF(some_value STREQUAL ${SOME_OTHER_VAR})
ENDIF(NOT SOME_VAR)
When running cmake on it, cmake throws an error like this:
CMakeLists.txt:10:
IF had incorrect arguments: some_value STREQUAL ${SOME_OTHER_VAR}
(Unknown
arguments specified).
I guess, what happens is, that cmake does not know about any variables
defined in the second IF (IF(NOT SOME_VAR)...), i.e. SOME_OTHER_VAR is
not
known to cmake's parser. But it complains about this missing variable
because it is used in another IF-statement (IF(some_value STREQUAL
${SOME_OTHER_VAR})...). This is strange, because cmake does not need to
parse the content of the second IF, if SOME_VAR is set to 1. Or it
should
parse the variables too.
If you define SOME_OTHER_VAR outside of the second IF, everything works
fine:
SET(SOME_VAR 1)
IF(SOME_VAR)
MESSAGE(SOME_VAR is set to true)
ENDIF(SOME_VAR)
SET(SOME_OTHER_VAR some_value)
IF(NOT SOME_VAR)
MESSAGE(SOME_VAR set to false)
IF(some_value STREQUAL ${SOME_OTHER_VAR})
MESSAGE(SOME_OTHER_VAR is set to some_value)
ENDIF(some_value STREQUAL ${SOME_OTHER_VAR})
ENDIF(NOT SOME_VAR)
It also works, if you put the content of the second IF-statement into a
separate file, which is included in the second if:
SET(SOME_VAR 1)
IF(SOME_VAR)
MESSAGE(SOME_VAR is set to true)
ENDIF(SOME_VAR)
IF(NOT SOME_VAR)
INCLUDE(include.cmake)
ENDIF(NOT SOME_VAR)
include.cmake is:
SET(SOME_OTHER_VAR some_value)
MESSAGE(SOME_VAR set to false)
IF(some_value STREQUAL ${SOME_OTHER_VAR})
MESSAGE(SOME_OTHER_VAR is set to some_value)
ENDIF(some_value STREQUAL ${SOME_OTHER_VAR})
Why does cmake work this way?
Cheers
Marco
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest, timeout per test/cmd
Yesterday I checked in some changes to that you can specify a timeout per test if desired. Essentially... add_test ( MyTest1 ) set_tests_properties ( MyTest1 PROPERTIES TIMEOUT 100) add_test ( MyTest2 ) set_tests_properties ( MyTest2 PROPERTIES TIMEOUT 500) etc... The timeout is specified in seconds. This feature should work in both dashboard and non-dashboard ctest invocations. Thanks Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest, timeout per test/cmd
There are two ways to globally put a time limit on each test IIRC. One is
to set DART_TESTING_TIMEOUT (see Modules/CTest.cmake) to the number of
seconds to let a test run, the other is to set CTEST_TEST_TIMEOUT in your
ctest script IIRC. I do not believe there is a way to do it on a per test
basis, but... with SET_TESTS_PROPERTIES it would be easy to add as a new
feature to CMake.
Thanks
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre
Sent: Monday, January 22, 2007 2:47 PM
To: CMake ML
Subject: [CMake] ctest, timeout per test/cmd
Hi,
Is it possible to add a timeout per test or a global timeout to be
used for each test (and not a maximum execution time for the complete
ctest session)?
Or is it possible to tell how the test should be called? So I can use
something like (${EXECUTABLE_OUTPUT_PATH}/${test_name} sleep 30;
kill -9 %1).
Thanks,
--Pierre
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest, timeout per test/cmd
The problem with DART_TESTING_TIMEOUT and CTEST_TEST_TIMEOUT is that they apply to the complete test suites. What I'm trying to solve is some infinite loops test cases, I like the tests to fail/timeout but the next tests should be executed as well. Just to make sure we are on the same page :) DART_TESTING_TIMEOUT applies to each test. Once one times out the next will start. It is not a limit for the entire process but for each test. Each test is given DART_TESTING_TIMEOUT seconds to complete independent of the time any other test took to run. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake]: Bug in ADD_LIBRARY
Yup, I'l check in a fix for it. add_executable does it correctly.
Thanks
Ken
Ken Martin PhD
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
wedekind
Sent: Thursday, January 04, 2007 12:39 PM
To: cmake@cmake.org
Subject: [CMake]: Bug in ADD_LIBRARY
Hello all,
I guess, I've found a bug in ADD_LIBRARY. As you know, its syntax is:
ADD_LIBRARY(libname [SHARED | STATIC | MODULE] [EXCLUDE_FROM_ALL]
source1 source2 ... sourceN)
If you specify both EXCLUDE_FROM_ALL _and_ [SHARED | STATIC | MODULE],
EXCLUDE_FROM_ALL is not considered, e.g.:
ADD_LIBRARY(someLib SHARED EXCLUDE_FROM_ALL someCode.cpp)
The ADD_LIBRARY command is not checking for a third argument to ADD_LIBRARY
in bool cmAddLibraryCommand::InitialPass(...).
Adding this:
if(s != args.end())
{
if(*s == EXCLUDE_FROM_ALL)
{
++s;
in_all = false;
}
}
after checking the second argument to ADD_LIBRARY should fix it.
Maybe other commands using EXCLUDE_FROM_ALL are also affected?
I am using a 1-month old check-out of CMake from cvs. I cannot update at the
moment... Did you already fix this?
Cheers
Marco
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: Weird if nesting problem
This has been fixed in cmake CVS now - Ken
IF(1)
ELSE(1)
FIND_PROGRAM(P_1 p_1)
FIND_PROGRAM(P_2 p_2)
IF(EXISTS ${P_1} AND EXISTS ${P_2} )
ELSE(EXISTS ${P_1} AND EXISTS ${P_2} )
ENDIF(EXISTS ${P_1} AND EXISTS ${P_2} )
ENDIF(1)
So :) This is effectively an implementation bug. I suspect it can be fixed
reasonably easily and when I get a sec I will try to fix it up. This fails
because P_1 and P_2 may be empty resulting in IF (EXISTS AND EXISTS) which
is an error. In fact for this case they will almost certainly be empty
because the FIND_PROGRAM calls do not get made. You might think the nested
IF call would also not get made, but it does :) The implementation is such
that the tracking of nested ifs involves evaluating their arguments even
if they are inside a scope that is not being executed. No other commands
get executed inside such a scope except for IF. And in this case the
arguments are not valid because P_1 and P_2 have not been found (as we
didn't execute the FIND_PROGRAM) commands. It should be fixed as it is
very counter intuitive (and actually computationally slower than it needs
to be) so feel free to create a bug report and assign it to me if you can.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: Weird if nesting problem
IF(1)
ELSE(1)
FIND_PROGRAM(P_1 p_1)
FIND_PROGRAM(P_2 p_2)
IF(EXISTS ${P_1} AND EXISTS ${P_2} )
ELSE(EXISTS ${P_1} AND EXISTS ${P_2} )
ENDIF(EXISTS ${P_1} AND EXISTS ${P_2} )
ENDIF(1)
So :) This is effectively an implementation bug. I suspect it can be fixed
reasonably easily and when I get a sec I will try to fix it up. This fails
because P_1 and P_2 may be empty resulting in IF (EXISTS AND EXISTS) which
is an error. In fact for this case they will almost certainly be empty
because the FIND_PROGRAM calls do not get made. You might think the nested
IF call would also not get made, but it does :) The implementation is such
that the tracking of nested ifs involves evaluating their arguments even if
they are inside a scope that is not being executed. No other commands get
executed inside such a scope except for IF. And in this case the arguments
are not valid because P_1 and P_2 have not been found (as we didn't execute
the FIND_PROGRAM) commands. It should be fixed as it is very counter
intuitive (and actually computationally slower than it needs to be) so feel
free to create a bug report and assign it to me if you can.
Thanks
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] elseif request
So ... if(cond1) block of statements elseif(cond2) block of statements elseif(cond3) block of statements ... elseif(condn) block of statements else(cond1) block of statements endif(cond1) And with LOOSE set if(cond1) block of statements elseif(cond2) block of statements elseif(cond3) block of statements ... elseif(condn) block of statements else() block of statements endif() Seems like a reasonable idea to me and I think it can be implemented fairly easily. Folks who like more strict closing structures can nest their IF statements as is currently done. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] a dependency nag/bug
Furthermore could it be made so that the default target in subdirs are fast and that you'd have to write something special (like /slow) to make it like today. Personally I tend not to like having the default option be fast (aka unsafe) although we have debated both sides of it. To me the naïve invocation should be safe and the special invocation should be the unsafe one. So if someone types make in a subdir it should properly build the targets of that subdir including any out of date targets in other directories that they depend on. Make foo should produce a valid result. Make foo/fast will try to build foo without updating other targets that it depends on but it may fail to link or produce an out of date foo depending on the state of those other targets. The /fast says I know what I am doing and I am telling cmake to skip some steps that should normally be done to ensure a properly built target. This is an area we are looking to improve (subdir build performance) and I do not think we are married to any one policy yet. Thanks Ken P.S. the /fast targets are in the subdir Makefile as well. You can do cd foodir; make foo/fast at least in CVS cmake and I'm pretty sure it is in 2.4.2 as well. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] cmake 2.2 / 2.4 differences?
Is there a list of important changes between 2.2 / 2.4? (also when exactly was 2.4 released?) Bill did send out and email with the major changes I believe with the 2.4.2 announcement as well as earlier ones. (e.g. must be in the cmake ml archive) This also in relation to the official book : Mastering CMake 2.2, how much is compatible with 2.4? The book was finished up around when 2.2.2 was released so it does take into account some of the changes that were made after 2.2.0. I think 2.4 is fully compatible (or very very close) with 2.2 except that it adds some capabilities and compiler support (mainly OSX and VS). For example custom commands in 2.2 can only have one command while in 2.4 any number are supported. The book does not cover CPack as that did not exist in 2.2 and is still evolving in 2.4 with some documentation on the Wiki. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] case in IF statements
From bug id #3119 I looked into this. The issue is that NOT is an argument to the if command and currently arguments are not case insensitive. To make this change and be consistent we would need to modify every command in cmake to be case insensitive to its arguments which might be a good idea, but is a bit of work and currently not on the agenda. This becomes more confusing for commands where a file name is an argument because in those cases (for UNIX) the arguments really are case sensitive. The same applies to many string type functions. We could say only keyword arguments to functions are case insensitive but for now I think it is easiest to leave it as is. -Original Message- From: [EMAIL PROTECTED] [mailto:cmake- [EMAIL PROTECTED] On Behalf Of Karl Merkley Sent: Thursday, June 15, 2006 12:06 PM To: cmake@cmake.org Subject: [CMake] case in IF statements I'm playing with cmake 2.4-2. I read recently that had been changed to accept lower case arguments (if instead of IF). However, it appears that modifiers within the IF statement still must be upper cased. For example, if (NOT UNIX) appears to work but if (not UNIX) fails. I noticed the same behavior with AND, MATCHES and STREQUAL in an IF statement.Is this by design or is it a bug? Karl ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Makefile build progress support
I have added progress reporting to the makefile based builds. It is checked into CMake CVS and should work with any make and parallel builds. The percentage done is based on source file counts without knowing if the source files are up to date or not. Specifically the progress is not a good indicator of time left except for clean builds, it is an indicator of source files left to consider and possibly build, if that makes any sense :) Progress is supported for the top level all target and for all top level cmake executable/library targets. It has had limited testing so let me know if it fails etc. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] a backwards compatible language simplification
Do you plan to also remove the parenthesis in a future release ? Gaetan My patch also made any unparenthesized cmake macro/function call FOO equivalent to the same call without any arguments FOO() This required some changes to the parser/scanner. I'd be happy to regenerate it off cvs trunk, if there's interest... I did run through I'm currently planning on leaving the parenthesis in. Some of the syntax highlighting modes for editors require it, it keeps the syntax simple, and once you type the () you really never have to change them. All pretty minor issues but then the benefit is fairly minor as well. I do want to support the same change as this for ENDMACRO since that is inconsistent right now in comparison to ENDIF, ENDWHILE, and ENDFOREACH. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] a backwards compatible language simplification
I incorporated some changes from Lloyd's patch and committed it to CVS. Basically if a project sets CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS on then you can leave off the arguments for the endif endwhile, else and endforeach commands. For example: if (FOO AND BAR) else () endif () The parenthesis are still required. I'm not sure what everyone's thoughts are on this but there it is... Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] cmake ruby bindings (or perl, or python, or ...)
The more and more I work with cmake, the more it feels like there are two (or more) distinct tools rolled into one... the front end is a piece of software that interprets CMakeLists.txt files, and drives a back end. The back end is the stuff that actually generates compiler specific project files (makefiles, whatever). I'm wondering if anyone feels the same way? Specifically I would be interested in using/writing a ruby front end for writing my build files in. This would give me powerful cross platform constructs for interacting with the file system (FILE()), list/set/hash manipulation, etc, and would give me a back end set of calls to drive the build file generation. The cost of course would be (for me as a user) having to have both ruby and cmake installed. The present front end seems like it will always be useful to keep cmake a tight self contained piece of software... My (very under cooked) thoughts are that a code restructuring could take place that would expose hooks into a generation engine that could then be exposed to other languages (via SWIG, or manually, or whatever). The existing front end would use that code. Is anyone interested in this kinda thinking? Is there any previous work in this direction? Well if CMake is architected correctly then there should be a nice line between the language parsing and execution. And it is close to that but not quite there :) I did briefly consider incorporating Lua into an experimental CMake just to see what the list files looked like and how clean the integration would be. But my intent was more curiosity and to clean up the architecture of CMake than to seriously put forth an alternate language binding. On the good side I was able to CMakeify LUA in just a couple minutes. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] a backwards compatible language simplification
Having spent all day hacking a massive project using cmake, I wonder...
could this
FOREACH (foo ${foolist})
IF (${foo} STREQUAL bar)
...
ELSE (${foo} STREQUAL bar)
...
ENDIF (${foo} STREQUAL bar)
ENDFOREACH (foo ${foolist})
change to this:
FOREACH (foo ${foolist})
IF (${foo} STREQUAL bar)
...
ELSE
...
ENDIF
ENDFOREACH
Temporarily supporting gunk after the ELSE/ENDIF/ENDFOREACH for migration?
Well the ENDFOREACH only needs the iteration variable so your example could
be changed to:
FOREACH (foo ${foolist})
IF (${foo} STREQUAL bar)
...
ELSE (${foo} STREQUAL bar)
...
ENDIF (${foo} STREQUAL bar)
ENDFOREACH (foo)
But to answer the meat of your question I do not think it can be trivially
changed to not require the extra text but I'll try to take a look at it over
the next few days. Personally I like the extra text but I certainly
understand how it might drive some folks batty.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMakeifying Boost
CMake has a great book published that tells a lot of stuff. CMake has a great Mailing list were users exchange information constantly, and As an update, the third edition of the book was sent to the printers a few weeks ago and should be in stock either Friday this week or early next week. It includes some nice cleanups and some new content and has been updated of course to reflect recent changes in CMake etc. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
