On Monday 05 November 2012, David Cole wrote:
I would prefer squish3_add_test and squish4_add_test, as the version number
goes with squish, not with the add_test... Keep the old macros and
functions with the same name and same meaning please. We've had too many
backwards incompatible
I like squish_v3_add_test the best: keeps the conventional prefix, but
still indicates the version it goes with.
On Mon, Nov 5, 2012 at 12:23 PM, Alexander Neundorf neund...@kde.org wrote:
On Monday 05 November 2012, David Cole wrote:
I would prefer squish3_add_test and squish4_add_test, as the
On Monday 05 November 2012, David Cole wrote:
I like squish_v3_add_test the best: keeps the conventional prefix, but
still indicates the version it goes with.
Ok, done.
This is in the MakeSquish4Work on the cmake stage.
Any objections to merging this into next ?
Alex
--
Powered by
No objections here. That's at least going to smoke test the module for us.
Has this been *really* tested on Windows? (Can the bug reporter test
out the changes as you've made them? Presumably he tested similar
changes in his own copy when he attached the patches to the bug.)
On Mon, Nov 5, 2012
On Monday 05 November 2012, David Cole wrote:
No objections here. That's at least going to smoke test the module for us.
Has this been *really* tested on Windows? (Can the bug reporter test
out the changes as you've made them? Presumably he tested similar
changes in his own copy when he
Great! Thanks for the info.
On Mon, Nov 5, 2012 at 2:23 PM, Alexander Neundorf neund...@kde.org wrote:
On Monday 05 November 2012, David Cole wrote:
No objections here. That's at least going to smoke test the module for us.
Has this been *really* tested on Windows? (Can the bug reporter test
Hi,
yesterday I pushed the TI_DSP_Compiler branch to cmake stage:
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/TI_DSP_Compiler
This is a compiler for the DSPs from Texas Instruments, which are e.g.
included in the OMAP processors.
There's a ticket for it too:
I don't have time to try it, but it looks reasonable upon inspection.
If it works for you, and works for him. merge to 'next' and let's
get it into 2.8.11.
On Mon, Nov 5, 2012 at 2:32 PM, Alexander Neundorf neund...@kde.org wrote:
Hi,
yesterday I pushed the TI_DSP_Compiler branch to
On 11/05/2012 02:59 PM, David Cole wrote:
I don't have time to try it, but it looks reasonable upon inspection.
If it works for you, and works for him. merge to 'next' and let's
get it into 2.8.11.
Yes.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
(the default for Ubuntu 12.10). gcov is also at
version 4.7.2.
Here are the first few lines of the output I get (there are tons more like
this):
$ make coverage
Site: djembefola
Build name: Linux-c++
Determine Nightly Start Time
Specified time: 00:00:00 EDT
Create new tag: 20121105-0400 - Nightly
Hi
NSIS seems to be quite outdated and no longer developed, are there any plans
to suppport new installer systems on Windows (e.g. the ones provided by Visual
Studio) ?
regards
--
Bogdan
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
2012/11/5 Bogdan Cristea crist...@gmail.com:
Hi
NSIS seems to be quite outdated and no longer developed,
There seems to be relatively recent commit in the repository though:
http://nsis.svn.sourceforge.net/viewvc/nsis/NSIS/trunk/
there is some evolution there as well:
On Monday 05 November 2012 13:57:04 you wrote:
There seems to be relatively recent commit in the repository though:
http://nsis.svn.sourceforge.net/viewvc/nsis/NSIS/trunk/
The latest release is 2.46, December 2009. I have not tried yet the version
from trunk, but I have noticed in Win8 some
2012/11/5 Bogdan Cristea crist...@gmail.com:
On Monday 05 November 2012 13:57:04 you wrote:
There seems to be relatively recent commit in the repository though:
http://nsis.svn.sourceforge.net/viewvc/nsis/NSIS/trunk/
The latest release is 2.46, December 2009. I have not tried yet the version
On 11/04/2012 07:59 PM, Bradley Giesbrecht wrote:
The problem is in commit e7e613e. Patching Darwin.cmake back to revision
43b74793 solves the problem.
The breakage is here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7e613efbf1da45a2a9e51d11a4022589d79c642
Thanks for tracking it
Hi
got some issues compiling ASM of Mac, mixed with other C++ code. In my CMake
file I use:
INCLUDE(CheckLanguage)
check_language(ASM)
if(CMAKE_ASM_COMPILER)
enable_language(ASM)
LIST(APPEND nm_tls_ALL_src src/FlowScalarField64.asm)
Hi again
Using ASM_NASM works better except the nasm call seems to get all the CXX
flags, some of them (-F) being invalid.
FAILED: /usr/bin/nasm -Iproducts/4DMove/tools/sediment
-I../../products/4DMove/tools/sediment -I../../products/4DMove
-I../../products/4DMove/utilities -Iproducts/4DMove
On Monday 05 November 2012, Mike Krus wrote:
Hi
got some issues compiling ASM of Mac, mixed with other C++ code. In my
CMake file I use:
INCLUDE(CheckLanguage)
check_language(ASM)
if(CMAKE_ASM_COMPILER)
enable_language(ASM)
On Monday 05 November 2012, Marshall, Rob wrote:
Is the intent of the find_package() macro to be used to locate prebuilt
third party libraries that have Include and library files prebuilt?
Or can it be used in a scenario where third party source is on the local
file system but will be built
On Monday 05 November 2012, Mike Krus wrote:
Hi
got some issues compiling ASM of Mac, mixed with other C++ code. In my
CMake file I use:
INCLUDE(CheckLanguage)
check_language(ASM)
if(CMAKE_ASM_COMPILER)
enable_language(ASM)
On Monday 05 November 2012, Mike Krus wrote:
Hi again
Using ASM_NASM works better except the nasm call seems to get all the CXX
flags, some of them (-F) being invalid.
This is what is being set in Modules/CMakeASM_NASMInformation.cmake, which
should be used:
Hi,
On Mon, Nov 5, 2012 at 7:57 AM, Brad King brad.k...@kitware.com wrote:
On 11/04/2012 07:59 PM, Bradley Giesbrecht wrote:
The problem is in commit e7e613e. Patching Darwin.cmake back to revision
43b74793 solves the problem.
The breakage is here:
On Nov 5, 2012, at 12:44 PM, Matthew Brett wrote:
Hi,
On Mon, Nov 5, 2012 at 7:57 AM, Brad King brad.k...@kitware.com wrote:
On 11/04/2012 07:59 PM, Bradley Giesbrecht wrote:
The problem is in commit e7e613e. Patching Darwin.cmake back to revision
43b74793 solves the problem.
The
I have several libraries in my build that are declared in the same
CMakeLists.txt (by add_library). Unfortunately, the Visual Studio generator
(2010, but I don't think it matters) puts CMakeFiles\generate.stamp in the
output directory for that CMakeLists.txt. Unless I'm mistaken, when being
I'm using a custom target to copy files to the following directory:
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIGURATION
This works on Visual Studio generators, because binaries that are
compiled are placed in the directory above.
However, if I generate for NMake on Windows, binaries are placed in
Are you on Windows Vista or higher? If so, have you tried running
Visual Studio as Administrator and doing a build? I don't have this
problem, but my first thought was that maybe you are having some
permissions errors. I also have several targets that build in parallel
in the same directory.
On
Sorry I got confused, what I needed to use is CMAKE_CFG_INTDIR.
On Mon, Nov 5, 2012 at 5:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
I'm using a custom target to copy files to the following directory:
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIGURATION
This works on Visual Studio
I'll ask my team about what circumstances it's been hit in, but I would expect
a permission error to happen every time, whereas this failure is intermittent.
-Original Message-
From: rcdai...@gmail.com [mailto:rcdai...@gmail.com] On Behalf Of Robert Dailey
Are you on Windows Vista or
I have a project that occasionally says it cannot access it's .ilk file;
but rerunning the build and it works usuaully... but it's only that one
project that has the problem, and an incremental link file is only for that
project
On Mon, Nov 5, 2012 at 3:49 PM, Todd Greer tgr...@affinegy.com
Hi,
On Mon, Nov 5, 2012 at 12:44 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Mon, Nov 5, 2012 at 7:57 AM, Brad King brad.k...@kitware.com wrote:
On 11/04/2012 07:59 PM, Bradley Giesbrecht wrote:
The problem is in commit e7e613e. Patching Darwin.cmake back to revision
43b74793
On 11/5/2012 8:31 PM, Matthew Brett wrote:
Is there something else I can do to find out where the problem is?
make VERBOSE=1 with both and see what the difference is with the link lines.
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
Hi,
On Mon, Nov 5, 2012 at 5:47 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 11/5/2012 8:31 PM, Matthew Brett wrote:
Is there something else I can do to find out where the problem is?
make VERBOSE=1 with both and see what the difference is with the link lines.
Thanks for the hint.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6a480dcb4ebdbe1df053e8887dabf523aeda0edc (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4b28c6123bdf4dfa0f415305b725835fa54164f9 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6620acb134abe93d036a0489abe1c2d38eba2088 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a7afaf87a91d71482e1dbdf3f56c75ed0165c6d5 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via cb082443aa2ea6dc09b86af5303b483d7019033c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1d9fe30505fe31863ac7ebc8bde633f096b44065 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via e727794a6eb42dfeac999f2c6531ea7f6dbd614c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4bb7d79e6967a30e5aa9c65e77fb3a7b49d6c249 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8316b91b9740f79d9a4250534d6fce5adbd73b34 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 7623edbf9e3ca301e26274fd6e8b26d22579961a (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2a59496..5bd83ca 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20121105
43 matches
Mail list logo
