Sounds wonderful, I'd love some more dev activity in #cmake. Announce it in
good time and I'll try my best to be there.
-Johan (GMT+1)
On Wed, Aug 15, 2012 at 7:58 PM, Alexander Neundorf neund...@kde.orgwrote:
**
On Wednesday 15 August 2012, David Cole wrote:
This is a good idea.
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13479
==
Reported By:Markus Blatt
Assigned To:
Hi,
we are using cmake in big build environment with Visual Studio and
Xoreax IncrediBuild. For debugging purpose we have turned on printing
commandlines in IncrediBuild. This produces lines like:
Generating res/resource_config.h
Configuration: MachSimIntegrationSample -
Dear All,
I have particular problem with the cmake generated output file naming
conventions (like myfile.cpp.o, myfile.cpp.gcno, ).
These naming conventions creating trouble for me to run gcov *.cpp properly
with my -o /objdir option (I had to copy them in the same directory without
the .ccp
It's merged now.
It's a ninja bug. I hope this ninja patch
https://github.com/martine/ninja/pull/401
is the right solution.
Peter
Original-Nachricht
Datum: Wed, 15 Aug 2012 20:59:26 +
Von: Malfettone, Kris kris.malfett...@sig.com
An: Bill Hoffman
That variable exists already, but it is named CTEST_CUSTOM_ERROR_EXCEPTION
See this wiki page:
http://cmake.org/Wiki/CMake/Testing_With_CTest#Customizing_CTest
Put that variable in a file called CTestCustom.cmake in your build tree.
CTEST_CUSTOM_ERROR_EXCEPTION and the variables like it are
Hi David,
thank you very much, I was a blockhead! Always being in touch
with C++ exceptions, I assumed this variable was doing something
with exceptions ... looking at this now, this does not make any
sense at all.
Thank you for enlightening,
Kiwi
On 17.08.2012 12:24, David Cole wrote:
That
Hey CMake Developers,
I recently came across the need to detect the architecture of the compilation
target in CMake (i.e. i386, x86_64, ppc, ia64, etc.). I was rather surprised to
find that CMake apparently doesn't have a function or variable to do this, as
such can be useful for things like
Dear all
I have this very strange case that on some hardware architectures
(powerpc, s390, s390x) CMake somehow fails to generate the
target-directories (/path/to/build-tree/CMakeFiles/libname.dir).
Have you ever encountered this problem?
If you're curious, here's the build log of one such
Guess: Maybe the + in the build tree directory name is messing something
up?
Are there + characters in the build tree names on architectures that work?
On Fri, Aug 17, 2012 at 8:01 AM, Michael Wild them...@gmail.com wrote:
Dear all
I have this very strange case that on some hardware
Yes, e.g. i386 works fine:
https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%2Bdfsg-1stamp=1345172639
It seems that only the more exotic (non-Intel) ones have this issue. I
forgot to mention that mipsel and sparc have the same problem. Except
for mipsel they are all
On 8/17/2012 5:03 AM, Sumit Adhikari wrote:
I have particular problem with the cmake generated output file naming
conventions (like myfile.cpp.o, myfile.cpp.gcno, ).
Object file names are computed in a deterministic manner
based only on the source file name and location. The
object name
CMake 2.8.9-2 is now available on Cygwin mirrors. This is a cygwin only
patch release. The only difference between 2.8.9-1 and 2.8.9-2 is the
addition of the ccmake which was inadvertently left out of the 2.8.9-1
release.
Thanks.
-Bill
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you
Dear Brad,
Thanks for the info. I will try and I find any issues then will report.
*.cpp was just symbolic.
Regards,
Sumit
On Fri, Aug 17, 2012 at 3:22 PM, Brad King brad.k...@kitware.com wrote:
On 8/17/2012 5:03 AM, Sumit Adhikari wrote:
I have particular problem with the cmake generated
Now I am doing good. Thanks for the info.
By the way, why not making this a feature (instead of keeping it as an
internal variable with a chance that it gets dropped in future). A
suggestion though :)
Regards,
Sumit
On Fri, Aug 17, 2012 at 3:22 PM, Brad King brad.k...@kitware.com wrote:
On
BTW, I found that using lcov is much easier than trying to figure out
the raw gcov output and it handles the output file naming automatically too.
Michael
On 08/17/2012 04:22 PM, Sumit Adhikari wrote:
Now I am doing good. Thanks for the info.
By the way, why not making this a feature
On 8/17/2012 9:44 AM, Sumit Adhikari wrote:
Dear Brad,
Thanks for the info. I will try and I find any issues then will report.
*.cpp was just symbolic.
Ctest works just fine with gcov and the current names of the .o files.
I am wondering why you are having trouble with this in the first
Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:
Yes, e.g. i386 works fine:
https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%
2Bdfsg-1stamp=1345172639
It seems that only the more exotic (non-Intel) ones have this issue. I
forgot to mention that mipsel and
On Fri, Aug 17, 2012 at 11:16 AM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:
Yes, e.g. i386 works fine:
https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%
2Bdfsg-1stamp=1345172639
It seems that only the
I understand your concern! Assume that for some reason I cannot use Ctest!
And all the problem starts there.
On Fri, Aug 17, 2012 at 4:31 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
On 8/17/2012 9:44 AM, Sumit Adhikari wrote:
Dear Brad,
Thanks for the info. I will try and I find any
On 8/17/2012 12:07 PM, Sumit Adhikari wrote:
I understand your concern! Assume that for some reason I cannot use
Ctest! And all the problem starts there.
I get that. But why can't you do what CTest does to use gcov?
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY
(well, the title was too good to pass up.)
I am having problems with FindX11 on Mac OS 10.7 (Lion). FindX11
unpredictably finds libraries in /usr/X11R6/lib and symbolic links to
libraries in /opt/local/lib (the MacPorts port library.) On Lion, the
Apple X server files always reside in
On Fri, Aug 17, 2012 at 3:36 PM, Randolph M. Fritz rfr...@lbl.gov wrote:
(well, the title was too good to pass up.)
I am having problems with FindX11 on Mac OS 10.7 (Lion). FindX11
unpredictably finds libraries in /usr/X11R6/lib and symbolic links to
libraries in /opt/local/lib (the MacPorts
I've already looked at the cmake tutorial, and it isn't that great. It
starts really simple but then goes into really complex things that most
people might not even use.
Also, there is currently no such thing as 'The Openlayer community' -
the project is unsupported, and no longer in active
I have set up a cmake structure that runs unit tests under valgrind
and by themselves using ctest and generating xml reports for CI
systems like Jenkins.
One drawback though, the directories to store the resulting reports
must exist before make test or make ExperimentalMemCheck are run.
How
Yep, pretty darn close. One caveat is that done this way it makes the
directory in the source dir. Had to use the CMAKE_BINARY_DIR
variables to make it in the build area...something I failed to mention
I needed before.
Thanks a bunch!
On Fri, Aug 17, 2012 at 5:42 PM, Jake Petroules
[This may be a repost. If you're seeing it twice, my apologies.]
On 2012-08-17 20:28:40 +, Clifford Yapp said:
BRL-CAD attempts to address this with a combination of a module for
managing Fink and MacPorts search paths and our own variation on
FindX11.cmake: […]
Thanks!
Not sure how
Disclaimer - I'm just learning cmake. I read as much as I could before
posting.
I am attempting to use Cmake 2.8.8 to create a to create a VS2010 SLN file.
I have MS Visual Studio 10, Intel Fortran XE 12.1.2.278 and MSVC
16.00.40219.01 all installed and work for other mixed language solutions
On 8/17/2012 9:19 PM, DonRobinson wrote:
Disclaimer - I'm just learning cmake. I read as much as I could before
posting. I am attempting to use Cmake 2.8.8 to create a to create a
VS2010 SLN file. I have MS Visual Studio 10, Intel Fortran XE 12.1.2.278
and MSVC 16.00.40219.01 all installed and
Thanks!
I'll give it a try next week.
Donald Robinson
Sr. Systems Ecologist
ESSA Technologies Ltd.
Vancouver, Canada
www.essa.com
604.535.1997
- audio, video, disco
From: Bill Hoffman [via CMake]
[mailto:ml-node+s3232098n7581287...@n2.nabble.com]
Sent: Friday, August 17, 2012 8:35
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 84ec0eee461f97f0f80dd522153ed000cf3a4216 (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 bff5c2968716edc750a256b8f66c588af50b80bf (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 2b5ea38ce9a47e5b7ca234d7fda7570e3e8d0d44 (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 f8133bf98febcd02690548edfbe476aaabdd0623 (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 f9c04e2f1738d06b4a23549b32f5a7a6e708abcc (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 95b33da..c514d2b 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 9)
-set(CMake_VERSION_TWEAK 20120817
36 matches
Mail list logo
