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
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
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
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
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
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:
:
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
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
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
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
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.
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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) ! :-)
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
76 matches
Mail list logo
