Re: [CMake] Waf build tool
Quoting Brandon Van Every [EMAIL PROTECTED]: On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: In summary, thanks. But, no thanks. With all those problems I did not even bother checking the speed. I got a chuckle out of their self-description on http://www.ohloh.net/tags/build/make , which one might view as a short list of open source build tools. Though it comes last in the arena of the build systems, we believe that Waf is a vastly superior alternative to its competitors (Autotools, Scons, Cmake, Ant, etc) for building software, and especially for open-source projects Yep, that's why it's in the top tier of Popular tools! :-) There's something to be said for tooting your own horn, but not to the extent of making oneself soft or complacent about a competitor's capabilities. I think the day that CMake has really won the build tool wars, we'll be seeing shelfs full of books at Barnes Noble and tons of jobs listing it as a must have skill. I wonder where Waf thinks it is, relative to all of that. Happy with the $0 we really don't have to bother with Windows open source market? It's not only waf does not care about Windows but they explicitly do not want to support it. That's the reason why KDE4 is using CMake instead of SCons or waf. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: community swelling due to standard languages
On Dec 18, 2007 2:21 AM, Brandon Van Every [EMAIL PROTECTED] wrote: Reading http://blog.aslakhellesoy.com/tags/jruby/ I get the impression that the Ruby + Java universe has a *lot* of developers banging on things. Maybe it wouldn't all be good! :-) Maybe too many cooks spoil the broth and one ends up with community schisms on build tool approaches. Or maybe they join forces. http://blog.foemmel.com/jrake JRake and Raven Jan 29, 2007 Just a quick note to let everyone know that Matthieu Riou (creator of Raven) and I have decide to join forces, and are currently in the process of merging the JRake and Raven codebases. The work is being done in the Raven repository over at Rubyforge, for those of you who would like to follow along. The combined effort will eventually become Raven 2.0. Coming Next In Raven http://offthelip.org/?p=45 I don't know quite what to make of it, personally. Other than it's worth watching what these guys are up to. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
Quoting Brandon Van Every [EMAIL PROTECTED]: beefing up CMake with PCRE and a few more string processing routines is an obvious and easy improvement to the product. I'm working on that, by the way. PCREs have been actually easy to implement, including your wishes about outputting the matches directly to variables instead of using REGEX_REPLACE (PCRE_REPLACE in our case), etc. I also took a look at the IF command implementation and I'm going to implement PCREs there, too: IF(variable PCRE_MATCHES pcre_regex) / IF(string PCRE_MATCHES pcre_regex). The most difficult part is understanding the really odd (at least to me) behavior of REGEX_MATCH and REGEX_REPLACE in current CMake (I'd like PCRE to mimic as much as possible). There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the deadline for PCREs to be included in CMake 2.6.0 would be, nothing. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] PCRE progress
On Dec 18, 2007 3:31 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: I also took a look at the IF command implementation and I'm going to implement PCREs there, too: IF(variable PCRE_MATCHES pcre_regex) / IF(string PCRE_MATCHES pcre_regex). Cool! I wonder if a GLOBAL property CMAKE_PCRE_DEFAULT would be appropriate at some point, after PCRE is proven. The most difficult part is understanding the really odd (at least to me) behavior of REGEX_MATCH and REGEX_REPLACE in current CMake (I'd like PCRE to mimic as much as possible). What is odd? MATCH matches the 1st match. REGEX REPLACE replaces all the matches. It's odd that they're not parallel, but they're not odd notions in and of themselves. There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the deadline for PCREs to be included in CMake 2.6.0 would be, nothing. Dunno there. I'm not seeing any downside to PCRE, so long as it's disambiguated from CMake's current regexes. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Dec 18, 2007 3:08 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: It's not only waf does not care about Windows but they explicitly do not want to support it. That's the reason why KDE4 is using CMake instead of SCons or waf. Heh! Well it's no different than the FSF's attitude with GNU Autoconf and GMake. Screw Windows is a meme that will die, I think. I mean, as big as Linux has become, Windows is still not going anywhere. We'll be doing cross-platform dances for quite some time. Meanwhile you've got Macs emulating Windows or dual-booting Windows because that's what consumers actually want. MS has majorly screwed up with Vista, but I don't think the Linux crowd is profiting from that, I think Apple is. I think we're all pretty settled that Autoconf and GMake are gonna die. It's only a question of what tools people will migrate to. I agree with Alan that CMake will gain many converts in the near term. I don't agree that it has to stay that way. You know, in a lot of ways the FSF is guilty of providing us with really stable stuff, but really old stuff. For instance, the FSF couldn't get GNU/Hurd done, so GNU/Linux took over. Screw Windows is all very fine and well, but if the pace of your RD is glacial, the rest of the open source industry isn't going to sit around waiting for your Windows-killing software. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Coverage without bullseye?
Hi, from http://www.cmake.org/Wiki/CTest:Coverage I seem to understand that coverage can be analyzed in the dart dashboard only by purchasing Bullseye. Is that true? If not, how to submit coverage analysis to the dashboard? Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Coverage without bullseye?
Salvatore Iovene wrote: Hi, from http://www.cmake.org/Wiki/CTest:Coverage I seem to understand that coverage can be analyzed in the dart dashboard only by purchasing Bullseye. Is that true? If not, how to submit coverage analysis to the dashboard? Uhhh... How about the first paragraph of that wiki page: http://www.cmake.org/Wiki/CTest:Coverage#Coverage_With_C.2B.2B Currently, you can do coverage with gcc gcov or bullseye (in CVS CMake only). See the Coverage section here for examples: http://public.kitware.com/dashboard.php?name=cmake Here is a ctest script used to do gcc coverage: http://www.cmake.org/Testing/Sites/dash17.kitware/Linux-g++4.0/20071218-0100-Nightly/Notes.html -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parsing cmake command line parameters
Rodolfo Schulz de Lima wrote: Alexander Neundorf escreveu: If you can find some spare time, there is a command argument parser in CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake. Using this in cmake is the first step in getting better support for custom command line parameters. A patch would be very welcome. Currently I don't have the time. I think I'll have some spare time to do this on this weekend, I'd be glad to help if there's enough coordination to avoid unnecessary work duplication. Second idea: maybe it would already help if the command line arguments to cmake would be available via a special cmake variable. Is there anything which speaks against this, Bill ? IMHO, we should differentiate between --enable/--disable and --with/--without, like it is on autotools' configure. The former used to enable/disable features, the other to compile with/without some external library. There's also the ubiquitous --prefix that should be mapped to CMAKE_INSTALL_PREFIX, and the others that commonly appear when we execute 'configure --help'. It should be nice to have a framework to facilitate working with enable/disable and with/without. The other common arguments that maps to cmake variables should be set up by default. The real problem with the command line arguments is how to gather them up for a project. I really have yet figured out a clean way to do that. People will want access to all options in the project, but I don't see a way to do that... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
Alexander Neundorf wrote: On Monday 17 December 2007, Brandon Van Every wrote: I propose the addition of a BOOL type to the CMake language. bool(variable [value]) would declare a variable of type BOOL, with an optional value supplied. Any SET commands performed on the variable in its scope would be subject to boolean type constraint. A BOOL can take on the following values. Any other assignment is an error. TRUE class - TRUE, 1, Y, Yes, YES, y, yes, ON FALSE class - FALSE, 0, N, n, No, NO, OFF, empty Attached is a patch which removes Y and N from the recognized values for true/false. This patch may break stuff. I don't know if there are many people who rely on N and Y. I am sure it will break something I don't think we can change it now. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parsing cmake command line parameters
Rodolfo Schulz de Lima wrote: Alexander Neundorf escreveu: If you can find some spare time, there is a command argument parser in CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake. Using this in cmake is the first step in getting better support for custom command line parameters. A patch would be very welcome. Currently I don't have the time. I think I'll have some spare time to do this on this weekend, I'd be glad to help if there's enough coordination to avoid unnecessary work duplication. Second idea: maybe it would already help if the command line arguments to cmake would be available via a special cmake variable. Is there anything which speaks against this, Bill ? IMHO, we should differentiate between --enable/--disable and -- with/--without, like it is on autotools' configure. The former used to enable/disable features, the other to compile with/without some external library. There's also the ubiquitous --prefix that should be mapped to CMAKE_INSTALL_PREFIX, and the others that commonly appear when we execute 'configure --help'. It should be nice to have a framework to facilitate working with enable/disable and with/without. The other common arguments that maps to cmake variables should be set up by default. The real problem with the command line arguments is how to gather them up for a project. I really have yet figured out a clean way to do that. People will want access to all options in the project, but I don't see a way to do that... -Bill What is it that people want beyond - DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE could provide? Do they want: --enable-build_this_that_whatever? I also don't understand why we have to parse the whole CMakeLists.txt structure. We should treat these command line args like we cache variables like CPack does when you configure different builds. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Dec 18, 2007, at 9:16 AM, Bill Hoffman wrote: Alexander Neundorf wrote: On Monday 17 December 2007, Brandon Van Every wrote: I propose the addition of a BOOL type to the CMake language. bool(variable [value]) would declare a variable of type BOOL, with an optional value supplied. Any SET commands performed on the variable in its scope would be subject to boolean type constraint. A BOOL can take on the following values. Any other assignment is an error. TRUE class - TRUE, 1, Y, Yes, YES, y, yes, ON FALSE class - FALSE, 0, N, n, No, NO, OFF, empty Attached is a patch which removes Y and N from the recognized values for true/false. This patch may break stuff. I don't know if there are many people who rely on N and Y. I am sure it will break something I don't think we can change it now. -Bill I might kindly disagree. There are many instances where backward compatibility was broken in order to clean things up and move on. Vtk 4.x to 5.x was one of those. My code broke with the 5.x release BUT it was for the better. And more importantly I was given plenty of notice that it was coming. The jump from 2.4 to 2.6 seems like a good time to make the break and clean things up. As long as there is a comprehensive list of breakage I don't think people will have a real problem with it. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
Alexander Neundorf wrote:
On Monday 17 December 2007, Brandon Van Every wrote:
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
would be subject to boolean type constraint. A BOOL can take on
the
following values. Any other assignment is an error.
TRUE class - TRUE, 1, Y, Yes, YES, y, yes, ON
FALSE class - FALSE, 0, N, n, No, NO, OFF, empty
Attached is a patch which removes Y and N from the recognized
values for true/false.
This patch may break stuff. I don't know if there are many people
who rely on N and Y.
I am sure it will break something I don't think we can change
it now.
-Bill
I might kindly disagree. There are many instances where backward
compatibility was broken in order to clean things up and move on.
Vtk 4.x to 5.x was one of those. My code broke with the 5.x release
BUT it was for the better. And more importantly I was given plenty
of notice that it was coming. The jump from 2.4 to 2.6 seems like a
good time to make the break and clean things up. As long as there
is a comprehensive list of breakage I don't think people will have
a real problem with it.
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
I also agree that trying to maintain backwards compatibility to the
detriment of the future can become a hinderance. I just had a
collegue who was extreemly frustrated for several hours with why his
build didn't work, only to discover that he should have been using
ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from
CMake stating that he shouldn't be using it (I would argue that CMake
should warn about the use of SUBDIRS).
Aside from the backwards compatibility issue, this cmake code should
work, but it produces a FATAL_ERROR:
SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
SET(A TRUE)
SET(B FALSE)
IF(A EQUAL B)
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ELSE()
MESSAGE(${A} should equal ${B})
ENDIF()
SET(B 1)
IF(A EQUAL B)
MESSAGE(${A} should equal ${B})
ELSE()
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ENDIF()
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
Mike Jackson wrote: I might kindly disagree. There are many instances where backward compatibility was broken in order to clean things up and move on. Vtk 4.x to 5.x was one of those. My code broke with the 5.x release BUT it was for the better. And more importantly I was given plenty of notice that it was coming. The jump from 2.4 to 2.6 seems like a good time to make the break and clean things up. As long as there is a comprehensive list of breakage I don't think people will have a real problem with it. Sure, but when you moved from VTK 4.x to 5.x you got compile time errors. If we change this, something will most likely silently fail. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to the
detriment of the future can become a hinderance. I just had a collegue
who was extreemly frustrated for several hours with why his build didn't
work, only to discover that he should have been using ADD_SUBDIRECTORIES
instead of SUBDIRS. There was no warning from CMake stating that he
shouldn't be using it (I would argue that CMake should warn about the
use of SUBDIRS).
That would be lots of warnings! SUBDIRS was the only way to do things
for a long time. CMake itself still uses them so it can be bootstrapped
with older versions of CMake. SUBDIRS still works, it just works
different. The behavior of both are documented.
Aside from the backwards compatibility issue, this cmake code should
work, but it produces a FATAL_ERROR:
SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
SET(A TRUE)
SET(B FALSE)
IF(A EQUAL B)
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ELSE()
MESSAGE(${A} should equal ${B})
ENDIF()
SET(B 1)
IF(A EQUAL B)
MESSAGE(${A} should equal ${B})
ELSE()
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ENDIF()
Why should TRUE EQUAL 1?
From the docs of IF:
IF(variable LESS number)
IF(string LESS number)
IF(variable GREATER number)
IF(string GREATER number)
IF(variable EQUAL number)
IF(string EQUAL number)
True if the given string or variable's value is a valid number and the
inequality or equality is true.
TRUE is not a valid number, EQUAL only works on numbers.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
Quoting Bill Hoffman [EMAIL PROTECTED]: Mike Jackson wrote: I might kindly disagree. There are many instances where backward compatibility was broken in order to clean things up and move on. Vtk 4.x to 5.x was one of those. My code broke with the 5.x release BUT it was for the better. And more importantly I was given plenty of notice that it was coming. The jump from 2.4 to 2.6 seems like a good time to make the break and clean things up. As long as there is a comprehensive list of breakage I don't think people will have a real problem with it. Sure, but when you moved from VTK 4.x to 5.x you got compile time errors. If we change this, something will most likely silently fail. What about doing the opposite of what Alex' patch did? What about making Y, YES, 1, ON synonyms? It's more or less what Brandon proposed but without introducing a BOOL(variable bool_value) command. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack install directory
Hi, After looking at the source code I found in CPack/cmCPackDebGenerator.cxx that if CPACK_PACKAGING_INSTALL_PREFIX is not set then it is set to /usr. Then the data.tar.gz is creating from directory usr. First this code will give an understandable error if the user sets CPACK_PACKAGING_INSTALL_PREFIX to something else than /usr. Secondly this doesn't allow the debian package to install files anywhere. This insertion of a usr directory is done I suppose to allow the tar command not to add the control, debian-binary, and itself. One way to get ride of this is to remove the usr insertion, do the tar first like this: (tar cfz ../data.tar.gz .), copy it to the current directory, remove it from the previous location. Then do the rest of the work like before. This of course can be optimised. This way actually works for me. Is there any other reason to do the insertion of the usr directory? Raphael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] question on linux release builds
Hi, Sorry if this is a duplicate message, forgot I wasn't subscribed to the list. When we create a linux build, and set the compile flag to 'release', no optimizations are actually performed, right? We need to pass that flag to 'make', right, something like: make -O2 otherwise, there's really no difference between that and a debug compilation, right? )other than different target libraries you specify in the CMake.txt file yourself) Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to
the detriment of the future can become a hinderance. I just had a
collegue who was extreemly frustrated for several hours with why
his build didn't work, only to discover that he should have been
using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning
from CMake stating that he shouldn't be using it (I would argue
that CMake should warn about the use of SUBDIRS).
That would be lots of warnings! SUBDIRS was the only way to do
things for a long time. CMake itself still uses them so it can be
bootstrapped with older versions of CMake. SUBDIRS still works, it
just works different. The behavior of both are documented.
The ADD_SUBDIRECTORY command should be used instead of SUBDIRS
although SUBDIRS will still work.
There isn't a mention in the docs that SUBDIRS behaves differently to
ADD_SUBDIRECTORIES in the man page, just that it should work.
Part of the problem with my collegue is that he was copying code from
another part of the build system. He was new to cmake and hadn't
read the whole man page. He just assumed the one way he found to
traverse subdirectories was the one to use. It's really confusing to
have two ways to do basically the same thing with only subtle
differences.
I guess my argument is that changing syntax shouldn't be shied away
from, but it would be nice to have a way to flush out old code.
Aside from the backwards compatibility issue, this cmake code
should work, but it produces a FATAL_ERROR:
SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
SET(A TRUE)
SET(B FALSE)
IF(A EQUAL B)
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ELSE()
MESSAGE(${A} should equal ${B})
ENDIF()
SET(B 1)
IF(A EQUAL B)
MESSAGE(${A} should equal ${B})
ELSE()
MESSAGE(FATAL_ERROR ${A} shouldn't equal ${B})
ENDIF()
Why should TRUE EQUAL 1?
From the docs of IF:
IF(variable LESS number)
IF(string LESS number)
IF(variable GREATER number)
IF(string GREATER number)
IF(variable EQUAL number)
IF(string EQUAL number)
True if the given string or variable's value is a valid number and
the inequality or equality is true.
TRUE is not a valid number, EQUAL only works on numbers.
OK, then how would you write the equality to be agnostic to the type
of conditional?
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
James Bigler wrote:
What is it that people want beyond -DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE
could provide?
Do they want: --enable-build_this_that_whatever?
People that work with embedded systems might want a stripped down
version of a library, for instance. So disabling features might be a
strong use case.
I also don't understand why we have to parse the whole CMakeLists.txt
structure. We should treat these command line args like we cache
variables like CPack does when you configure different builds.
But in the first time cmake is run, there's no cache and no way to know
what are the command line parameters. Is must run the whole build to
know that. So the first time 'cmake . --help' runs, the whole build
should be parsed and executed.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
That is, the parameter is bound to another parameter? It's not
impossible to imagine a case where each time we run cmake --help, a
different set of parameters is shown. I know, that's stupid, but corner
cases usually are...
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: map structure on cmake script
Brandon Van Every wrote: Hmm, I wrote writhing a hash function, I wonder if that was a Freudian slip? That's the problem with English, you people throw H's everywhere in words! Throughout, although, though, thighs,... you don't know how hard it is for a non-native speaker write those correctly. But now that's completely off-topic, bailing out... :) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Using regex in find_program
There's a functionality that I'm missing in find_program(...). I must find an executable that matches a regex expression. What I'm trying to achieve is find the name of a cross-compiler. It would be mingw32-gcc, i585-mingw32msvc-gcc, etc... so I would match .*mingw32.*-gcc. Is there any other way to do this? Is it possible to extend find_program to cope with regexes? In my example, I would write: find_program(PROG REGEX .*mingw32.*-gcc) The first matching program name (along with its path) would be returned. If there's enough consensus that this should be implemented, I'm willing to do this... Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Dec 18, 2007 11:14 AM, Mike Jackson wrote: On Dec 18, 2007, at 10:07 AM, James Bigler wrote: On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote: James Bigler wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). That would be lots of warnings! SUBDIRS was the only way to do things for a long time. CMake itself still uses them so it can be bootstrapped with older versions of CMake. SUBDIRS still works, it just works different. The behavior of both are documented. The ADD_SUBDIRECTORY command should be used instead of SUBDIRS although SUBDIRS will still work. There isn't a mention in the docs that SUBDIRS behaves differently to ADD_SUBDIRECTORIES in the man page, just that it should work. Part of the problem with my collegue is that he was copying code from another part of the build system. He was new to cmake and hadn't read the whole man page. He just assumed the one way he found to traverse subdirectories was the one to use. It's really confusing to have two ways to do basically the same thing with only subtle differences. I guess my argument is that changing syntax shouldn't be shied away from, but it would be nice to have a way to flush out old code. Would it be possible to emit a warning when commands like subdirs are used? The warning is built into cmake and emits every time cmake is run? This would help motivate people to move to the newer commands? I know this has ramifications that I am not thinking of.. Bill basically answered this... It's too many warnings! So, how about only reporting the warning on the first time it encounters the deprecated command? Or having a CMAKE_SUPPRESS_DEPRECATION_COMMENTS (or something variable) and make sure that in the message there is a note. The message would be something like the following. Ideally it would be an automatically generated message to avoid duplicity in the help strings. --- WARNING: SUBDIRS is a deprecated command! Use the add_subdirectory() command instead. For more information use: cmake --help-command ADD_SUBDIRECTORIES or whatever else you feel like... If you would like to supress these deprecation warnings, put: SET(CMAKE_SUPPRESS_DEPRECATION_COMMENTS TRUE) on your root CMakeLists.txt file. --- Just my two cents. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using regex in find_program
Rodolfo Schulz de Lima wrote: There's a functionality that I'm missing in find_program(...). I must find an executable that matches a regex expression. What I'm trying to achieve is find the name of a cross-compiler. It would be mingw32-gcc, i585-mingw32msvc-gcc, etc... so I would match .*mingw32.*-gcc. Is there any other way to do this? Is it possible to extend find_program to cope with regexes? In my example, I would write: find_program(PROG REGEX .*mingw32.*-gcc) The first matching program name (along with its path) would be returned. If there's enough consensus that this should be implemented, I'm willing to do this... find_program(PROG NAMES name1 name2 name3) You have to list all the names explicitly, but you can have as many as you want. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Using regex in find_program
Bill Hoffman wrote: find_program(PROG NAMES name1 name2 name3) You have to list all the names explicitly, but you can have as many as you want. That's what I'm using right know, but this doesn't address the more general problem. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fortran
Hello CMake people I pushed myself during the last weekends to get more familiar with CMakes codebase. Not for fun only ;), but make me smart enough to sketch an approach for handling fortrans module dependencies. Bill, Brad, Alex ... it would be very nice if you're take a look at - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Introduction_to_the_problem - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Abstract_solution - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution I did some wild proof of concept coding, but its not ready be shown so far. (see the class definitions at http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution) Howevery, the process of - parsing sources and make the information persistent - -E fortran_module_scan - reload the information and generate depend.make - -E cmake_depends using the persistent information works for a simple exe-target with an arbitrary number of sources involving modules. The next thing is to handle modules provided by another target in the sourcetree. For convenience I'm temporary using boost.serialization for the persistent part. If the hole thing is in shape I will work cmakeish solution. The hardest thing for me is to decide how to alter the way Makefile(2) is generated i.e. where to trigger the module extraction. Some advice on this would be very helpfull. I will do best to apply your advises. ASAP I will provide a patch to make this issue less abstract. Best, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] question on linux release builds
You can look for the flag being used using ccmake and displaying advance flags. If you do so you will see that the release build do use different flag than debug build. On Dec 18, 2007 4:05 PM, Mark Wyszomierski [EMAIL PROTECTED] wrote: Hi, Sorry if this is a duplicate message, forgot I wasn't subscribed to the list. When we create a linux build, and set the compile flag to 'release', no optimizations are actually performed, right? We need to pass that flag to 'make', right, something like: make -O2 otherwise, there's really no difference between that and a debug compilation, right? )other than different target libraries you specify in the CMake.txt file yourself) Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Olivier Delannoy Ph.D. Student PRiSM Laboratory Versailles University, FRANCE ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran
Maik Beckmann wrote: Hello CMake people I pushed myself during the last weekends to get more familiar with CMakes codebase. Not for fun only ;), but make me smart enough to sketch an approach for handling fortrans module dependencies. Bill, Brad, Alex ... it would be very nice if you're take a look at - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Introduction_to_the_problem - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Abstract_solution - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution I did some wild proof of concept coding, but its not ready be shown so far. (see the class definitions at http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution) Howevery, the process of - parsing sources and make the information persistent - -E fortran_module_scan - reload the information and generate depend.make - -E cmake_depends using the persistent information works for a simple exe-target with an arbitrary number of sources involving modules. The next thing is to handle modules provided by another target in the sourcetree. For convenience I'm temporary using boost.serialization for the persistent part. If the hole thing is in shape I will work cmakeish solution. The hardest thing for me is to decide how to alter the way Makefile(2) is generated i.e. where to trigger the module extraction. Some advice on this would be very helpfull. I will do best to apply your advises. ASAP I will provide a patch to make this issue less abstract. Brad is actually working on fortran support right now. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Using regex in find_program
On Tuesday 18 December 2007, Rodolfo Schulz de Lima wrote: Bill Hoffman wrote: find_program(PROG NAMES name1 name2 name3) You have to list all the names explicitly, but you can have as many as you want. That's what I'm using right know, but this doesn't address the more general problem. That's right. As a practical solution, how about you add now the names you know of and if you get reports of other names you add these too ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Tuesday 18 December 2007, Rodolfo Schulz de Lima wrote:
James Bigler wrote:
What is it that people want beyond -DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE
could provide?
Do they want: --enable-build_this_that_whatever?
People that work with embedded systems might want a stripped down
version of a library, for instance. So disabling features might be a
strong use case.
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an option
around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
I also don't understand why we have to parse the whole CMakeLists.txt
structure. We should treat these command line args like we cache
variables like CPack does when you configure different builds.
But in the first time cmake is run, there's no cache and no way to know
what are the command line parameters. Is must run the whole build to
know that. So the first time 'cmake . --help' runs, the whole build
should be parsed and executed.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
That is, the parameter is bound to another parameter? It's not
impossible to imagine a case where each time we run cmake --help, a
different set of parameters is shown. I know, that's stupid, but corner
cases usually are...
Yes, and they must work too, otherwise there will be bug reports.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.
Or have a cmake modules, which handles this stuff, and which also creates a
custom target help-args or something like that, which prints the available
args. This would not be available before cmake has successfully run.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Using regex in find_program
Alexander Neundorf wrote: That's right. As a practical solution, how about you add now the names you know of and if you get reports of other names you add these too ? That's what I'm doing, but I think it's a common use case that might deserve a special support from cmake. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] General modernization facility
On Dec 18, 2007 9:36 AM, James Bigler [EMAIL PROTECTED] wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). General warning facilities, and a standard way of turning on future looking options, so that people do not have to be stuck in the past if they don't want to be, would be good. CMake CVS has the set_properties(GLOBAL PROPERTIES var1 value1 var2 value2 ...) mechanism. So if we didn't bother with the bool(var [value]) interface I proposed, we could selectively apply Alex's patch using set_properties(GLOBAL PROPERTIES ORDINARY_Y_N_STRINGS TRUE). Or maybe someone can think of a better name for it. Collections of options such as this could be put in a standard module called Modern. include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Flagging SUBDIRS as an error would be the kind of thing you'd stick into Modern. If a user does include(Modern), they're saying they want whatever is currently considered the best practice, even if that breaks something. It should be clearly documented as having that purpose. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Tuesday 18 December 2007, Bill Hoffman wrote: Attached is a patch which removes Y and N from the recognized values for true/false. This patch may break stuff. I don't know if there are many people who rely on N and Y. I am sure it will break something I don't think we can change it now. Could it be be done using CMAKE_BACKWARDS_COMPATIBILITY ? James Bigler wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). That would be lots of warnings! SUBDIRS was the only way to do things for a long time. CMake itself still uses them so it can be bootstrapped with older versions of CMake. SUBDIRS still works, it just works different. The behavior of both are documented. How about a command line switch --warn-deprecated, when used cmake prints a warning for each command which is marked as deprecated ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Dec 18, 2007 10:02 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: What about doing the opposite of what Alex' patch did? What about making Y, YES, 1, ON synonyms? It's more or less what Brandon proposed but without introducing a BOOL(variable bool_value) command. That's the exact opposite of why I made my proposal. I want the Y, YES, 1, ON, N, NO, OFF pollution *eliminated* from strings. I proposed bool(var [value]) because it doesn't break anything. It encapsulates the desired behavior in a type, same as a lot of programming languages do. Once encapsulated, I'd be free to set_properties(GLOBAL PROPERTIES REQUIRE_BOOL TRUE) and get rid of the string pollution. I'm happy, the backwards compatible crowd is happy. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran
Bill Hoffman wrote: Maik Beckmann wrote: Hello CMake people I pushed myself during the last weekends to get more familiar with CMakes codebase. Not for fun only ;), but make me smart enough to sketch an approach for handling fortrans module dependencies. Bill, Brad, Alex ... it would be very nice if you're take a look at - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Introduction_to_the_problem - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Abstract_solution - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution I did some wild proof of concept coding, but its not ready be shown so far. (see the class definitions at http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution) Howevery, the process of - parsing sources and make the information persistent - -E fortran_module_scan - reload the information and generate depend.make - -E cmake_depends using the persistent information works for a simple exe-target with an arbitrary number of sources involving modules. The next thing is to handle modules provided by another target in the sourcetree. For convenience I'm temporary using boost.serialization for the persistent part. If the hole thing is in shape I will work cmakeish solution. The hardest thing for me is to decide how to alter the way Makefile(2) is generated i.e. where to trigger the module extraction. Some advice on this would be very helpfull. I will do best to apply your advises. ASAP I will provide a patch to make this issue less abstract. Brad is actually working on fortran support right now. This is correct. I'll add some comments to the wiki. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
Alexander Neundorf wrote: I have (currently) two ideas: either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the custom command line parameters. There's a beauty in having everything inside CMakeLists.txt Or have a cmake modules, which handles this stuff, and which also creates a custom target help-args or something like that, which prints the available args. This would not be available before cmake has successfully run. This would be non-intuitive to people not accustomed to cmake. I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. But it's reasonable to create some arguments when cmake is running under Windows or Linux, etc. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. wxWidgets' configure script throws all possible options, whether they're valid for Windows or Linux. It's really a mess, but it's simple to implement and I've never heard of anyone complaining about it. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Dec 18, 2007 12:01 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. I disagree. Information hiding according to what's selected or possible is a perfectly valid way to interact with the user. Just because Autoconf listed every Tom, Dick, and Harry option flatly doesn't mean that CMake has to do it. The Autoconf listings are usually a bunch of boring boilerplate. The CMake approach is more powerful than what Autoconf provides; there are more ways for the programmer to cut off her fingers. So make the programmer responsible for what she does. Have a Chapter Oriented policy manual on how to implement command line options. Stress that if options are determined by complex conditionals, they're going to appear late in the help output. If the programmer wants the options to be readily apparent, she should determine them unconditionally or with constant conditions. A dry run through the CMake script is sufficient to determine any unconditional options. It's also sufficient for any conditions that are constants, such as the platform, generator, or compiler we're using. Or even variables that are defined early and don't change. Options that are masked by more complex conditionals can certainly be detected, and warnings can be issued about them. I think we need to stop thinking in terms of perfect solution and start thinking in terms of policy, where the programmer is responsible for implementing a policy. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. Exactly. Anything could happen is a lot of fretting about nothing. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack install directory
Hi, sorry, I don't understand everything you wrote. On Tuesday 18 December 2007, Raphael Cotty wrote: Hi, After looking at the source code I found in CPack/cmCPackDebGenerator.cxx that if CPACK_PACKAGING_INSTALL_PREFIX is not set then it is set to /usr. Then the data.tar.gz is creating from directory usr. First this code will give an understandable error if the user sets CPACK_PACKAGING_INSTALL_PREFIX to something else than /usr. Do you mean it is good that it gives an understandable error or that it is bad that there is an error ? Why do we get an error if it is set to something else ? Secondly this doesn't allow the debian package to install files anywhere. You mean installing the binary deb package to a different prefix than what it was intended for ? Is this supposed to work ? If you have RPATH in the files then it can't be installed to an arbitrary location. This insertion of a usr directory is done I suppose to allow the tar command not to add the control, debian-binary, and itself. One way to get ride of this is to remove the usr insertion, do the tar first like this: (tar cfz ../data.tar.gz .), copy it to the current directory, remove it from the previous location. Then do the rest of the work like before. This of course can be optimised. Can you please explain a bit more ? Thanks for the feedback Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Rodolfo Schulz de Lima wrote: Alexander Neundorf wrote: I have (currently) two ideas: either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the custom command line parameters. There's a beauty in having everything inside CMakeLists.txt Not only that, but this becomes a maintenance nightmare. It's too easy to get these out of sync. Or have a cmake modules, which handles this stuff, and which also creates a custom target help-args or something like that, which prints the available args. This would not be available before cmake has successfully run. This would be non-intuitive to people not accustomed to cmake. This isn't a problem if it's documented well. If cmake --help spit out something told the user what to do, they will usually do it. The problem lies when the programs don't behave as expected with no explanation (i.e. Using -DMY_VAR=value instead of -DMY_VAR:STRING=value should be rejected instead silently doing weird things). Having a good README or INSTALL file does wonders. That's the first thing I look for in a project. I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. But it's reasonable to create some arguments when cmake is running under Windows or Linux, etc. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. wxWidgets' configure script throws all possible options, whether they're valid for Windows or Linux. It's really a mess, but it's simple to implement and I've never heard of anyone complaining about it. So this isn't so much a discussion of being able to parse arguments from the command line, but rather an automated mechanism to detect options in the CMakeLists.txt files and print them out when a user does --help. Many autoconf systems don't do this. To see the real options I have to scan configure.in myself. For autoconf build systems I have generated, I have to manually add the help options. I think it's silly to try and solve this problem, especially when there is a much better way to do it via ccmake. I much prefer using ccmake than having the giant configure line. It seems like CMake already has a good way to configure builds, and those used to autoconf just need a little nudging. I haven't had anyone in my group complain about using ccmake. That being said, if you really want cmake --help-options, then I guess you would just have to parse all the CMakeLists.txt files, find all occurrences of ADD_ARG() regardless of scope, and spit them out. There really isn't a better option outside of just using ccmake. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Bill Hoffman wrote: Brandon Van Every wrote: Exactly. Anything could happen is a lot of fretting about nothing. I am thinking a separate file would be the best approach for this. Something like CMakeOptions.cmake, it gets read in and adds command line options to cmake. It can include other options files from inside the project. This idea of a pass on the cmakefiles is going to be very hard technically. We can push the work to the developer of the cmakelist files. When you create a project, you can put the options that you want into a separate file(s). I think this is a reasonable compromise. You already have to do this for autoconf, and if you don't want to mess with this, you could not implement one. The developer could also document that certain flags only have meanings for certain systems. We could also allow a *very* restricted set of system variables, such as WIN32 and APPLE. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack install directory
Hi, The first issue is that the debian packager is inserting a usr directory: If my CMAKE_INSTALL_PREFIX is /dev/install and in my CMakeLists.txt I have: INSTALL( FILES foo DESTINATION etc ) then the make install will copy foo to /dev/install/etc. Then the DEB packaging will create a debian package which will install foo in /usr/etc/. This is done in CPack/cmCPackDebGenerator.cxx, as I tried to explain in the previous post. I hope this is a bit clearer! Raphael On Dec 18, 2007 5:47 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Hi, sorry, I don't understand everything you wrote. On Tuesday 18 December 2007, Raphael Cotty wrote: Hi, After looking at the source code I found in CPack/cmCPackDebGenerator.cxx that if CPACK_PACKAGING_INSTALL_PREFIX is not set then it is set to /usr. Then the data.tar.gz is creating from directory usr. First this code will give an understandable error if the user sets CPACK_PACKAGING_INSTALL_PREFIX to something else than /usr. Do you mean it is good that it gives an understandable error or that it is bad that there is an error ? Why do we get an error if it is set to something else ? Secondly this doesn't allow the debian package to install files anywhere. You mean installing the binary deb package to a different prefix than what it was intended for ? Is this supposed to work ? If you have RPATH in the files then it can't be installed to an arbitrary location. This insertion of a usr directory is done I suppose to allow the tar command not to add the control, debian-binary, and itself. One way to get ride of this is to remove the usr insertion, do the tar first like this: (tar cfz ../data.tar.gz .), copy it to the current directory, remove it from the previous location. Then do the rest of the work like before. This of course can be optimised. Can you please explain a bit more ? Thanks for the feedback Alex ___ 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] General modernization facility
Brandon Van Every wrote: On Dec 18, 2007 9:36 AM, James Bigler [EMAIL PROTECTED] wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). General warning facilities, and a standard way of turning on future looking options, so that people do not have to be stuck in the past if they don't want to be, would be good. CMake CVS has the set_properties(GLOBAL PROPERTIES var1 value1 var2 value2 ...) mechanism. So if we didn't bother with the bool(var [value]) interface I proposed, we could selectively apply Alex's patch using set_properties(GLOBAL PROPERTIES ORDINARY_Y_N_STRINGS TRUE). Or maybe someone can think of a better name for it. Collections of options such as this could be put in a standard module called Modern. include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Flagging SUBDIRS as an error would be the kind of thing you'd stick into Modern. If a user does include(Modern), they're saying they want whatever is currently considered the best practice, even if that breaks something. It should be clearly documented as having that purpose. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Perhaps this could be enforced by CMAKE_BACKWARDS_COMPATIBILITY variable. If you supply a sufficiently modern version of cmake, then deprecated things will turn on warnings/errors. If you set the version lower, then features that were not deprecated at that version wouldn't issue warnings. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack install directory
On Tuesday 18 December 2007, Raphael Cotty wrote: Hi, The first issue is that the debian packager is inserting a usr directory: If my CMAKE_INSTALL_PREFIX is /dev/install and in my CMakeLists.txt I have: INSTALL( FILES foo DESTINATION etc ) then the make install will copy foo to /dev/install/etc. Then the DEB packaging will create a debian package which will install foo in /usr/etc/. This is done in CPack/cmCPackDebGenerator.cxx, as I tried to explain in the previous post. Ok. Would it help if CPACK_PACKAGING_INSTALL_PREFIX was initialized to CMAKE_INSTALL_PREFIX ? Is there a reason why this isn't the case ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack install directory
Hi, The packaging is done from the _CPack_Packages/Linux/DEB/$CPACK_PACKAGE_NAME$CPACK_PACKAGE_NAME dir. I suppose that CPack copies the files to install from the install dir to _CPack_Packages/Linux/DEB/$CPACK_PACKAGE_NAME$CPACK_PACKAGE_NAME/$CPACK_PACKAGING_INSTALL_PREFIX The data.tar.gz is built from _CPack_Packages/Linux/DEB/$CPACK_PACKAGE_NAME$CPACK_PACKAGE_NAME with a tar from an hardcoded usr directory. Because the tar can not be done like this: tar cvf data.tar.gz . (will in clude itself and the control files) then it's done from the created usr dir. Raph On Dec 18, 2007 6:10 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Tuesday 18 December 2007, Raphael Cotty wrote: Hi, The first issue is that the debian packager is inserting a usr directory: If my CMAKE_INSTALL_PREFIX is /dev/install and in my CMakeLists.txt I have: INSTALL( FILES foo DESTINATION etc ) then the make install will copy foo to /dev/install/etc. Then the DEB packaging will create a debian package which will install foo in /usr/etc/. This is done in CPack/cmCPackDebGenerator.cxx, as I tried to explain in the previous post. Ok. Would it help if CPACK_PACKAGING_INSTALL_PREFIX was initialized to CMAKE_INSTALL_PREFIX ? Is there a reason why this isn't the case ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Using FILE(REMOVE_RECURSE ...) on clean targets
What are the implications of using FILE(REMOVE_RECURSE ...) instead of FILE(REMOVE ...) on clean targets? I'm setting CMAKE_ADDITIONAL_CLEAN_FILES to a directory that isn't being removed. I've discovered that I must change REMOVE to REMOVE_RECURSE inside MakeFiles/project.dir/cmake_clean.cmake to have the directory removed. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] General modernization facility
On Dec 18, 2007 1:06 PM, James Bigler [EMAIL PROTECTED] wrote: Brandon Van Every wrote: include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Perhaps this could be enforced by CMAKE_BACKWARDS_COMPATIBILITY variable. If you supply a sufficiently modern version of cmake, then deprecated things will turn on warnings/errors. If you set the version lower, then features that were not deprecated at that version wouldn't issue warnings. How about include(ForwardsCompatibility). That would make the intent really clear. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 1:38 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: What are the implications of using FILE(REMOVE_RECURSE ...) instead of FILE(REMOVE ...) on clean targets? I thought REMOVE_RECURSE was a straightforward unconditional nuke. I don't see that cleanliness has anything to do with it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every wrote: How about include(ForwardsCompatibility). That would make the intent really clear. IMHO a better solution would be to specify which CMAKE version is expected to parse the CMakeFiles.txt. Hint: there's already the cmake_minimum_required command (at least in cmake-cvs, that is)... Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
Brandon Van Every wrote: I thought REMOVE_RECURSE was a straightforward unconditional nuke. I don't see that cleanliness has anything to do with it. Well, if I want to clean (remove) a directory, I'd expect it to be removed regardless if it contains subdirectories. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 1:44 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Brandon Van Every wrote: How about include(ForwardsCompatibility). That would make the intent really clear. IMHO a better solution would be to specify which CMAKE version is expected to parse the CMakeFiles.txt. Well, maybe ForwardsCompatibility doesn't make the intent as clear as I thought. The actual intent is for different CMake behaviors to exist side-by-side. Default behavior is whatever CMake currently does; usually pretty conservative in the interest of backwards compatibility. But the user could select a behavior like set_properties(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). That could be available in CMake 2.6.1, for instance. Parse it like 2.6.1 doesn't mean anything; it could be the default parsing or the CMAKE_REQUIRE_BOOL parsing. You'd need to have an option like CMAKE_REQUIRE_BOOL being used for a long time. You couldn't make it the default until CMake 2.8.0 or 2.10.0 or some such, after lots of people have voted with their feet and the old behavior is clearly legacy. Hint: there's already the cmake_minimum_required command (at least in cmake-cvs, that is)... cmake_minimum_required has been around for awhile now. It does not solve the problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 1:55 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
don't see that cleanliness has anything to do with it.
Well, if I want to clean (remove) a directory, I'd expect it to be
removed regardless if it contains subdirectories.
FILE commands are performed at configuration time. They don't have
any relevance to actions performed at build time. Not unless you've
wrapped them up in a CMake script and issued an ADD_CUSTOM_COMMAND of
the form COMMAND ${CMAKE_COMMAND} -P myscript.cmake.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
Brandon Van Every wrote:
FILE commands are performed at configuration time. They don't have
any relevance to actions performed at build time. Not unless you've
wrapped them up in a CMake script and issued an ADD_CUSTOM_COMMAND of
the form COMMAND ${CMAKE_COMMAND} -P myscript.cmake.
I think you misunderstood what I meant. Then we do 'make clear', the
CMakeFiles/project.dir/cmake_clean.cmake gets executed. That's where the
FILE(REMOVE ...) command I'm talking about resides. This is created by
cmake during build configuration, but IMHO it should be
FILE(REMOVE_RECURSE ...) so that 'make clean' removes any directories
specified with CMAKE_ADDITIONAL_CLEAN_FILES property.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every wrote: Hint: there's already the cmake_minimum_required command (at least in cmake-cvs, that is)... cmake_minimum_required has been around for awhile now. It does not solve the problem. Why is it so? If I'm using, say, 2.10.0 stuff, I'd issue a cmake_minimum_required(VERSION 2.10.0 FATAL_ERROR) and cmake would behave without having to cope with backwards compatibilities. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] question on linux release builds
Hi Olivier, Thanks, I do see that now with the advanced mode on. I am just confused on how this comes into use during actual compilation. I mean, my make file is generated in my project directory - but when I examine it, I don't see any mention about required libraries to link to, optimization level, etc. Shouldn't those be embedded inside the make file somehow? After CMake has generated the make file, I just go to the project dir through a console and type: make so how does make know what libs to link to, what optimization level to use if it's not stored in the make files? Thanks, Mark On Dec 18, 2007 11:18 AM, Olivier Delannoy [EMAIL PROTECTED] wrote: You can look for the flag being used using ccmake and displaying advance flags. If you do so you will see that the release build do use different flag than debug build. On Dec 18, 2007 4:05 PM, Mark Wyszomierski [EMAIL PROTECTED] wrote: Hi, Sorry if this is a duplicate message, forgot I wasn't subscribed to the list. When we create a linux build, and set the compile flag to 'release', no optimizations are actually performed, right? We need to pass that flag to 'make', right, something like: make -O2 otherwise, there's really no difference between that and a debug compilation, right? )other than different target libraries you specify in the CMake.txt file yourself) Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Olivier Delannoy Ph.D. Student PRiSM Laboratory Versailles University, FRANCE ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 2:36 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Hint: there's already the cmake_minimum_required command (at least in cmake-cvs, that is)... cmake_minimum_required has been around for awhile now. It does not solve the problem. Why is it so? If I'm using, say, 2.10.0 stuff, I'd issue a cmake_minimum_required(VERSION 2.10.0 FATAL_ERROR) and cmake would behave without having to cope with backwards compatibilities. Let's say really old code does cmake_minimum_required(VERSION 2.2.0 FATAL_ERROR). CMake 2.6.0 meets that minimum requirement. It should run the old code correctly, unless there's a really really good reason to break backwards compatibility. CMake 2.6.0 isn't going to have CMAKE_REQUIRE_BOOL, or any such newfangled change, as default behavior. It would break old code. cmake_minimum_required is a *minimum* requirement, not an exact requirement or a maximal requirement. We have to get from 2.6.0 to 2.8.0 to 2.10.0. Sure, in the distant future, CMAKE_REQUIRE_BOOL could be default behavior and cmake_minimum_required(VERSION 2.10.0 FATAL_ERROR) would be sufficient to enforce it. But we're not there yet. We'll have to go through 1, maybe 2 generations of CMake before enough people have voted with their feet to retire the legacy behavior. 2 generations before CMake is allowed to break ancient Y N Yes No ON' OFF code with impunity. And that's assuming people actually like bool() and adopt it wholesale. For any given feature, it's quite possible that the community will not accept it wholesale. In the worst case, we could be selecting CMAKE_REQUIRE_BOOL as an option indefinitely. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 2:33 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: I think you misunderstood what I meant. Then we do 'make clear', the CMakeFiles/project.dir/cmake_clean.cmake gets executed. That's where the FILE(REMOVE ...) command I'm talking about resides. This is created by cmake during build configuration, but IMHO it should be FILE(REMOVE_RECURSE ...) so that 'make clean' removes any directories specified with CMAKE_ADDITIONAL_CLEAN_FILES property. Sounds like a bug. File a reproducer in the bug tracker. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every wrote:
Let's say really old code does cmake_minimum_required(VERSION 2.2.0
FATAL_ERROR). CMake 2.6.0 meets that minimum requirement. It should
run the old code correctly, unless there's a really really good reason
to break backwards compatibility. CMake 2.6.0 isn't going to have
CMAKE_REQUIRE_BOOL, or any such newfangled change, as default
behavior. It would break old code. cmake_minimum_required is a
*minimum* requirement, not an exact requirement or a maximal
requirement.
Of course, stupid me... sorry.
But let's imagine that each feature has a minimum and possibly a maximum
cmake version where it's supported. So, if we specify in the script
which cmake version it is written to, in cmake code one could do
// This feature is valid from version 2.3.1 up to current version
// (2.6.0)
if(valid_versions(2.3.1,))
{
// implement feature1
}
// This other feature is valid from versions 2.3.4 to 2.4.3
if(valid_versions(2.3.4, 2.4.3)
{
// implement feature2
}
So, if we specify that the script expects cmake to be version 2.3.2,
only feature1 would be available. If the script is for version 2.4.0,
both feature1 and feature2 would be available. Finally, if we expect
cmake 2.5.4, feature1 would be in.
Now, say we're running an old cmake with a script written for a new
cmake. Simply it wouldn't accept to parse the script because it uses new
constructs. And finally the opposite, we have a new cmake parsing an old
script... the if's in cmake code would cope with backward capabilities.
Suppose we don't want to support feature1 no more in cmake 2.7. Well, we
just replace the first if condition to:
if(valid_versions(2.3.1,2.6.9)
{
// implement feature1
}
And that'll be it, 2.6.9 would be the last version where feature1 is
supported, but old scripts would run flawlessly.
I really think I've included every situation... but again, I might be
completely wrong. If so, sorry for the noise :)
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Tuesday 18 December 2007, Pau Garcia i Quiles wrote: ... There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the deadline for PCREs to be included in CMake 2.6.0 would be, nothing. I think one requirement would be that the pcre library is added under CMake/Utilities/ and converted to build with cmake. Kitware has the policy to have no extra dependencies for building cmake except a C++ compiler with STL. (ccmake etc. are optional). It's BSD licensed, that's good. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
Brandon Van Every wrote: Sounds like a bug. File a reproducer in the bug tracker. Yes, that's what I thought. I've filled bug report #6180 with a patch to correct this. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] attempt to summarize
Hi, there were a lot of emails, I'll try to make a summary. So what is needed to get a big market share for cmake and what seems to be required in cmake features. This is not intended to be a task list for Kitware, e.g. ant and the support for languages would be nice as contributions from somebody who actually uses that stuff. Support for the major build systems: Supported: make, MSVC, XCode, Eclipse, KDevelop, CodeBlocks Missing: -ant: I think having an ant generator might be nice (I don't know that much about ant). It will be nice for Java people, and it may be as powerful (if not more) and maybe cleaner than makefiles. Maybe people who don't like java could write an ant implementation in another language, maybe also as a library so IDEs could use it directly ? It would also mean that CMake generates (modern) XML files instead of (old fashioned) Makefiles. -any others ? -- Support for languages -- Fully supported: C, C++ Support not that mature as for C/C++: C# - not documented, but I think Kitware has some projects using C#, I guess cmake is used for them ? Java - I think I heard there are some issues with files in subdirectories ? Fortran - AFAIK some dependency scanner issues, is being worked on Assembler - is there, but almost no feedback Ada - Alan has files for that, not (yet) in cvs Not supported: Objective C - used on the Mac, would probably be good if it was supported OCaml - really strange to build, may be problematic, not that many users Pascal - may be not that hard to add, maybe less users than OCaml ? -- Operating systems -- Supported: all except the ones listed below needs improvements: OpenBSD, shared library versioning scheme not supported: VMS, OS/2, DOS, others ? CMake features parentheses in conditions: if((a OR b) AND (c OR d)) I guess square brackets would be acceptable too (just in case this would easier for the parser): if( [a OR b] AND [c OR d] ) some way to define custom command line arguments fine grained flags (per source etc.), AFAIK is being worked on something like BREAK and/or RETURN to break from loops, makros, functions and files. This should make some code easier to read and write. better regexps wouldn't hurt abstraction of compiler flags (being worked on ?) I could create a wiki page TODO items so interested people may pick something to work on. Comments ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
Quoting Alexander Neundorf [EMAIL PROTECTED]: On Tuesday 18 December 2007, Pau Garcia i Quiles wrote: ... There is one thing which discourages me, though: nobody from Kitware commented on the interest of PCREs, what the deadline for PCREs to be included in CMake 2.6.0 would be, nothing. I think one requirement would be that the pcre library is added under CMake/Utilities/ and converted to build with cmake. Kitware has the policy to have no extra dependencies for building cmake except a C++ compiler with STL. (ccmake etc. are optional). It's BSD licensed, that's good. I already have PCRE 7.4 under CMake/Utilities here and it builds using CMake. It was cmake-ified by Christian Ehrlicher from KDE4 on Windows fame. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] attempt to summarize
Quoting Alexander Neundorf [EMAIL PROTECTED]: Great summary, thanks. +1 to a TODO in the wiki. Hi, there were a lot of emails, I'll try to make a summary. So what is needed to get a big market share for cmake and what seems to be required in cmake features. This is not intended to be a task list for Kitware, e.g. ant and the support for languages would be nice as contributions from somebody who actually uses that stuff. Support for the major build systems: Supported: make, MSVC, XCode, Eclipse, KDevelop, CodeBlocks Missing: -ant: I think having an ant generator might be nice (I don't know that much about ant). It will be nice for Java people, and it may be as powerful (if not more) and maybe cleaner than makefiles. Maybe people who don't like java could write an ant implementation in another language, maybe also as a library so IDEs could use it directly ? It would also mean that CMake generates (modern) XML files instead of (old fashioned) Makefiles. -any others ? -- Support for languages -- Fully supported: C, C++ Support not that mature as for C/C++: C# - not documented, but I think Kitware has some projects using C#, I guess cmake is used for them ? Java - I think I heard there are some issues with files in subdirectories ? Fortran - AFAIK some dependency scanner issues, is being worked on Assembler - is there, but almost no feedback Ada - Alan has files for that, not (yet) in cvs Not supported: Objective C - used on the Mac, would probably be good if it was supported OCaml - really strange to build, may be problematic, not that many users Pascal - may be not that hard to add, maybe less users than OCaml ? -- Operating systems -- Supported: all except the ones listed below needs improvements: OpenBSD, shared library versioning scheme not supported: VMS, OS/2, DOS, others ? CMake features parentheses in conditions: if((a OR b) AND (c OR d)) I guess square brackets would be acceptable too (just in case this would easier for the parser): if( [a OR b] AND [c OR d] ) some way to define custom command line arguments fine grained flags (per source etc.), AFAIK is being worked on something like BREAK and/or RETURN to break from loops, makros, functions and files. This should make some code easier to read and write. better regexps wouldn't hurt abstraction of compiler flags (being worked on ?) I could create a wiki page TODO items so interested people may pick something to work on. Comments ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] attempt to summarize
Alexander Neundorf wrote: Not supported: Objective C - used on the Mac, would probably be good if it was supported This actually is supported, although in a limited way. You can add a .m file and cmake will build it on the Mac. Basically it depends on gcc knowing what to do with a .m file which it does on the Mac. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: attempt to summarize
Alexander Neundorf wrote: Hi, there were a lot of emails, I'll try to make a summary. So what is needed to get a big market share for cmake and what seems to be required in cmake features. This is not intended to be a task list for Kitware, e.g. ant and the support for languages would be nice as contributions from somebody who actually uses that stuff. Thanks for organizing those! Since it'll be on a wiki, I'd add 'lua language support', just to put it on the table for further debate whether we should strive for backwards compatibility in detriment to newer features or use a stronger script language and, might I add, solve at least 3 points you've mentioned. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] attempt to summarize
On Dec 18, 2007 4:08 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Missing: -ant: I think having an ant generator might be nice [...] It would also mean that CMake generates (modern) XML files instead of (old fashioned) Makefiles. -any others ? If someone wants to do Ant, and they're really really motivated, then they'll do Ant and I imagine CMake won't refuse their work. However, I'm not presently convinced that Ant, Maven 2, or XML-based build systems in general, are strategic. Although widely deployed, there are some indications that the Java universe doesn't think they're so hot after all. Wiser people have recognized that you really do need conditional logic to do a build system, and that hacking conditionals within the constraints of XML is extremely clunky. This is the origin of JRake, Raven, and Groovy. I would watch these tools, and similar, to see what kind of progress they make. If we had a crystal ball, we'd really like to know who's going to win the how do you script Java? wars. There are many offerings. No clear winners. In the same vein I'm thinking it's premature to commit to Lua. It may be more important to commit to whatever the Java universe commits to. Consider, for example, that embedding Ruby and shipping with possibly 4MB of source file bloat, would be acceptable if it emerged as the clear slam dunk de facto standard for building Java apps. But that wouldn't be for several years yet, if ever. I can't tell whether Raven is a really important project, or just 2 guys getting a lot of notoriety because nobody else is doing anything. Their mailing list certainly has a lot of crickets chirping. At some point next year I imagine we'll see what they're capable of. The performance differences between Python, Ruby, and Lua may also change in the next few years. People have worked on speeding Python and Ruby up. Maybe someone will finally succeed? I think migration technologies in general are worth investing in. This is a more technologically advanced proposition than hanging one's hat on Python, Ruby, or Lua and hoping that OO will confer competitive advantages. I think the money is tied up in moving from old build systems to new build systems, and making that job less labor intensive. I don't have any thoughts yet on what an ideal migration technology would look like. When I look at the Tiobe list of popular languages http://www.tiobe.com/tpci.htm , none of the top 20 languages are interesting as a basis for migration technology. With the possible exception of Lisp/Scheme. This says to me that industry doesn't know how to metaprogram. I do follow the Microsoft Research offerings a little bit. Perhaps they will push one of their languages into popularity. I think superior documentation and tutorial technologies are part of superior migration technologies. Many things could be done here. Often not the sort of thing that techies like to do though. CMake features better regexps wouldn't hurt Related: introduce bool type, remove boolean pollution from strings (Y, N, YES, NO, ON, OFF). Grabbing small character sequences to mean TRUE or FALSE is an unclean practice; I've demonstrated the errors it can introduce. NOTFOUND is a large character sequence and not so problematic. General mechanism for future-looking behaviors, so that we're not forever stuck with the argument it'll break backwards compatibility. I could create a wiki page TODO items so interested people may pick something to work on. Not sure that helps. Anything I suggested, I can implement. Others might get to it faster, and choose to run with it, but if no one else cares, I certainly will. I haven't met a lot of open source people who will just work on any old thing. Maybe such people exist, and maybe it's possible to marshal them into various things. But I think more is needed than a TODO list, to accomplish that. Someone has to actually lead on any given feature. This is why projects often use a bug tracker to organize this kind of stuff. The problem with a bug tracker is it doesn't tell you at-a-glance what people are working on. What we really need is a way to dump that information out of the bug tracker and display it on a webpage. Would this be as simple as defining a particular Mantis view, and then making a wiki page about using Mantis to examine that view? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 3:31 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: But let's imagine that each feature has a minimum and possibly a maximum cmake version where it's supported. So, if we specify in the script which cmake version it is written to, But old scripts don't do that. One could do it for new scripts, but old scripts are what they are. Also, I don't necessarily want my script to be limited to CMake's behavior when I wrote it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every escreveu: But old scripts don't do that. One could do it for new scripts, but old scripts are what they are. Also, I don't necessarily want my script to be limited to CMake's behavior when I wrote it. That would be easy to cope with, no version specification = 2.4.7. And when you write a script, you would set the version to the current version you're testing on. That would guarantee that this script will ALWAYS work, no matter how cmake evolves. That's a good deal. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 6:43 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: But old scripts don't do that. One could do it for new scripts, but old scripts are what they are. Also, I don't necessarily want my script to be limited to CMake's behavior when I wrote it. That would be easy to cope with, no version specification = 2.4.7. If it actually works under 2.4.7 and doesn't need some other earlier version to function with. And when you write a script, you would set the version to the current version you're testing on. That would guarantee that this script will ALWAYS work, no matter how cmake evolves. That's a good deal. What if 2.4.7 ships with an arguably bad behavior, 2.4.8 fixes it, and my code is stuck with the 2.4.7 behavior because you didn't think anyone was ever supposed to avail themselves of improvements? Cheers, Brandon ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every escreveu: That would be easy to cope with, no version specification = 2.4.7. If it actually works under 2.4.7 and doesn't need some other earlier version to function with. We would have to guarantee that version 2.4.7 executes correctly every script made up till now. What if 2.4.7 ships with an arguably bad behavior, 2.4.8 fixes it, and my code is stuck with the 2.4.7 behavior because you didn't think anyone was ever supposed to avail themselves of improvements? That would be a big mess, but if the script *works*, even with bad behavior, so be it. Maybe a warning should be emitted. The point is to guarantee that the script the author made will work the same way he intended, forever. It would be wrong if we changed the behavior the author relied upon. I think that this solution would let Kitware add disruptive features with ease. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
I didn't follow closely but... On Wednesday 19 December 2007, Rodolfo Lima wrote: That would be a big mess, but if the script *works*, even with bad behavior, so be it. Maybe a warning should be emitted. The point is to guarantee that the script the author made will work the same way he intended, forever. It would be wrong if we changed the behavior the author relied upon. I think that this solution would let Kitware add disruptive features with ease. This is wrong. This would mean that the old buggy behaviour in the code would have to stay in an if(version==2.4.7) block, and next to it the fixed block for newer versions. This is not maintainable. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Alexander Neundorf escreveu: This is wrong. This would mean that the old buggy behaviour in the code would have to stay in an if(version==2.4.7) block, and next to it the fixed block for newer versions. This is not maintainable. Well, isn't it what is happening with SUBDIRS vs. ADD_SUBDIRECTORY? How this problem is being handled now? And releasing a version with a buggy behavior is a serious issue. I'm not talking about bugs like when one feature is documented to do something bug does something else. This should be corrected without concerns about backwards compatibility. But a feature conceptually wrong shouldn't be allowed to go unnoticed. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 7:31 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: That would be easy to cope with, no version specification = 2.4.7. If it actually works under 2.4.7 and doesn't need some other earlier version to function with. We would have to guarantee that version 2.4.7 executes correctly every script made up till now. I don't see how we could. What if 2.4.7 ships with an arguably bad behavior, 2.4.8 fixes it, and my code is stuck with the 2.4.7 behavior because you didn't think anyone was ever supposed to avail themselves of improvements? That would be a big mess, but if the script *works*, even with bad behavior, so be it. Maybe a warning should be emitted. The point is to guarantee that the script the author made will work the same way he intended, forever. It would be wrong if we changed the behavior the author relied upon. The author may have been completely unaware of the potential of the error condition, having never seen the circumstances in which the error occurs. We don't know that I wrote this using 2.4.7 means I want it frozen for 2.4.7. Let's even say, for sake of argument, that you provided an interface for the author to state exactly that. version_freeze(2.4.7). It still may not be a good idea, because the author may not have full knowledge of the consequences of his decision. I think that this solution would let Kitware add disruptive features with ease. I don't think we need to tie disruptive features to version numbers. I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). I'm willing to wait a loong time for it to become a default CMake behavior. I think include(Modern) is a good idea in principle, for people who want to use a well-defined collection of forward looking behaviors. The idea may need refinement in practice, but the general idea is opt in. Not tie my hands. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 7:48 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Alexander Neundorf escreveu: This is wrong. This would mean that the old buggy behaviour in the code would have to stay in an if(version==2.4.7) block, and next to it the fixed block for newer versions. This is not maintainable. Well, isn't it what is happening with SUBDIRS vs. ADD_SUBDIRECTORY? How this problem is being handled now? They're non-conflicting commands. The reason there's a problem is because they do very similar things but have different behavior. Users don't know any better so they do stuff with SUBDIRS. CMake 2.6.0 will list SUBDIRS in the depreciated section of the documentation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every escreveu: We would have to guarantee that version 2.4.7 executes correctly every script made up till now. I don't see how we could. Well, Kitware has always been concerned with backward compatibility, so every script out there would work with cmake-2.4.7. I'd also throw cmake-cvs in the mix, since they still fight hard to maintain backward compatibility. The author may have been completely unaware of the potential of the error condition, having never seen the circumstances in which the error occurs. We don't know that I wrote this using 2.4.7 means I want it frozen for 2.4.7. Let's even say, for sake of argument, that you provided an interface for the author to state exactly that. version_freeze(2.4.7). It still may not be a good idea, because the author may not have full knowledge of the consequences of his decision. But if you correct the behaviour, the script wouldn't work as expected. Is this a good thing? Can you create an example of such error condition? I'm not saying that version_freeze(2.4.7) should maintain all bugs of cmake-2.4.7. No, those bugs should be corrected. Only the interface to the user would be frozen. For instance, version_freeze(2.4.7) would interpret Y, TRUE, YES as being the same thing. version_freeze(2.6.0) wouldn't. I don't think we need to tie disruptive features to version numbers. I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). I'm willing to wait a loong time for it to become a default CMake behavior. I think include(Modern) is a good idea in principle, for people who want to use a well-defined collection of forward looking behaviors. The idea may need refinement in practice, but the general idea is opt in. Not tie my hands. If you turn something into default behavior, it'll break backward compatibility. And as time goes by, the amount of disruptive features tends to grow. In the future to write a script I would have to write lot of set_property(GLOBAL PROPERTIES CMAKE_REQUIRE...)... It'd be better to specify the version of cmake I'm working on and that's it. Regards, rod PS: feel free to correct any English mistakes I make. I won't learn if I keep writing wrongly. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Bug with cmake's `--debug-trycompile' option?
Anybody has any idea? On Dec 11, 2007 5:07 PM, Clark J. Wang [EMAIL PROTECTED] wrote: I have a CMakeLists.txt like this: PROJECT(foo) SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE) INCLUDE(CheckIncludeFile) CHECK_INCLUDE_FILE(poll.h VAR1) CHECK_INCLUDE_FILE(sys/event.h VAR2) When I run `cmake .' it outputed like this: -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for poll.h -- Looking for poll.h - found -- Looking for sys/event.h -- Looking for sys/event.h - not found -- Configuring done -- Generating done -- Build files have been written to: /root/void/cmake/check_include_file/build This is fine for `sys/event.h' is not available on my system. But when I run `cmake --debug-trycompile .' it outputed like this: debug trycompile on -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for poll.h -- Looking for poll.h - found -- Looking for sys/event.h -- Looking for sys/event.h - found -- Configuring done -- Generating done -- Build files have been written to: /root/void/cmake/check_include_file/build This time it said that `sys/event.h' was found! Anything wrong? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Bug with cmake's `--debug-trycompile' option?
Clark J. Wang wrote: Anybody has any idea? On Dec 11, 2007 5:07 PM, Clark J. Wang [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I This is fine for `sys/event.h' is not available on my system. But when I run `cmake --debug-trycompile .' it outputed like this: This time it said that `sys/event.h' was found! Anything wrong? I am not surprised. The debug-try compile option does not clean out the build tree. It is meant as a debugging tool only. It should not be expected to work. Usually, if there is trouble with the result of a try compile, you set it up so that only that one try compile will happen and run with debug-trycompile. Then cmake will leave the build/source files in the temp directory, so you can try it by hand, and examine the results. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Alexander Neundorf wrote:
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an option
around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
No, it isn't *just* a matter of syntax (which is also horrible, btw).
It is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:
add_option( NAME TYPE HELP [OPTS] )
with OPTS being:
CONFIGURATION Debug
REQUIRED someotheroption
That avoids the need for if-thens.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.
Yuck!
Or have a cmake modules, which handles this stuff, and which also creates a
custom target help-args or something like that, which prints the available
args. This would not be available before cmake has successfully run.
Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.
It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
