Am Donnerstag, 18. Dezember 2014, 12:23:38 schrieb Daniel Pfeifer:
Hi,
I would like to know what the oldest versions of GCC and Visual Studio are
that should be able to compile the CMake source code. I was unable to find
any information about that.
I expected the oldest supported version
Brad King wrote:
On 12/14/2014 08:36 AM, Rolf Eike Beer wrote:
The idea behind this API in OpenBSD is: if you are looking for the pseudo
numbers you need to call srand_deterministic(), i.e. you must explicitely
state that you want the not really random random numbers. Everyone else
David Cole wrote:
Sounds to me like the perfect thing to just ignore till the dust settles.
Yes, this will probably take a while until this shows up in a release version
of OpenBSD. But if this is not reverted then it will probably be a good idea
to have check for this in 3.2 ready so it will
Am Samstag, 13. Dezember 2014, 13:05:00 schrieben Sie:
On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers
wrote:
Yes, setting an explicit seed should make subsequent calls to random
be deterministic...
Well, *we* want that, but I don't think that OpenBSD is making an
Am 10.12.2014 15:38, schrieb Ben Boeckel:
Hi,
It appears[1] as though OpenBSD has changed srand and rand which we use
in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a
no-op there.
Do we want to use rand_deterministic and srand_determinitic or does it
not matter?
From
Brad King wrote:
On 12/02/2014 12:06 PM, Thompson, KT wrote:
# GSL_ROOT_DIR - The top level directory of the discovered GSL
# install (useful if GSL is not in a standard
location)
This and the other singular names should be documented as variables
that are
Am Dienstag, 18. November 2014, 12:31:15 schrieb Ben Boeckel:
On Tue, Nov 18, 2014 at 18:06:30 +0100, Gregor Jasny wrote:
On 18/11/14 17:19, Ben Boeckel wrote:
I wonder if we should
fix anything about it and if so, make continue behave in an analogous
way
You want to make
Fraser Hutchison wrote:
Hi there,
CMake 3.1 (both release candidates) now generate a CMP0054 warning when
configuring the following CMakeLists.txt in a clean build folder with MSVC
as the generator:
cmake_minimum_required(VERSION 2.8)
enable_language(ASM_MASM)
The warning is:
CMake
Am Samstag, 15. November 2014, 02:27:40 schrieb Ruslan Baratov via cmake-
developers:
On 14-Nov-14 22:58, Brad King wrote:
- Please add more test cases covering all the file(LOCK)
argument processing error messages.
Done. Also I've found parse issue which is based on `sscanf`
Am Donnerstag, 13. November 2014, 11:19:26 schrieb Brad King:
On 11/12/2014 06:08 PM, Domen Vrankar wrote:
Attached is the final patch.
Applied with minor tweaks, thanks:
string: Tolerate SUBSTRING length exceeding end index
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=474bbb9d
Am Donnerstag, 13. November 2014, 13:07:52 schrieben Sie:
On 11/13/2014 12:48 PM, Rolf Eike Beer wrote:
This should be a good addition, no?
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 56d9b66..66717ef 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules
Am Donnerstag, 6. November 2014, 10:37:25 schrieb Chuck Atkins:
Hi Eike,
So, it seems that voyager has no issue, only pioneer, which I'm just taking
as coincidence from differences in various binary sizes. However, from
looking at the error log, the link line for cmake shows:
Am Donnerstag, 6. November 2014, 10:58:36 schrieben Sie:
Aha! I'll change it to MATCHES instead of STREQUALS and that should do it
since technically the issue is with both 32 and 64 bit architectures, it
just might not have shown up yet on both. Perhaps the build name for the
dashboard
Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
On 11/06/2014 12:00 PM, Chuck Atkins wrote:
I added an HP-UX block and adjusted the logic to be a bit more
consistent with the other determine system blocks
Looks good to me, assuming the test for parisc on hpux is correct.
Am Mittwoch, 5. November 2014, 10:38:14 schrieben Sie:
So, it seems nothing changed. Looking at the log though, it looks like the
flags aren't even getting used. Can you check the output of uname with
it's various options? I suspect the result might not be exactly parisc.
voyager ~ # uname
Am Dienstag, 4. November 2014, 11:27:24 schrieb Chuck Atkins:
stage/fix-gcc-hppa
Add -mlong-calls for gcc on HPPA. Merged to next for testing.
Sorry,
saw this mail only after I mailed you privately because I looked into the
commit log first. For general consumption, here are the relevant
Am Dienstag, 4. November 2014, 16:17:08 schrieb Chuck Atkins:
Please make sure you also add these to bootstrap.sh.
Will do.
And please see the very end of
CompileFlags.cmake where we already added workarounds for HPPA. Until now
we have not seen the problem on HP-UX, so this has been
Am 27.10.2014 14:27, schrieb Brad King:
On 10/24/2014 05:46 PM, Evgeny Kalishenko wrote:
Documentation added, authorship fixed, a couple of commits squashed.
Great. Applied and merged for testing:
CPackRPM: Support pre(post) install scripts
Am Montag, 27. Oktober 2014, 10:55:50 schrieb Brad King:
On 10/27/2014 10:41 AM, Rolf Eike Beer wrote:
if(${_RPM_SPEC_HEADER} MATCHES REQUIRES_PRE OR
${_RPM_SPEC_HEADER} MATCHES REQUIRES_POST)
This should really be using STREQUAL and not using dereferences on the
left hand side
Am Mittwoch, 8. Oktober 2014, 10:54:12 schrieb Brad King:
On 10/07/2014 12:18 PM, Rolf Eike Beer wrote:
+ add_library(CMake::Threads INTERFACE IMPORTED GLOBAL)
Both issues should be fixed now.
Thanks. Your use of an interface target for this is a clever way
of abstracting
Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King:
On 10/08/2014 11:37 AM, Rolf Eike Beer wrote:
All credits go to Timo Rothenpieler
Okay. Please add a Co-Author: or Inspired-by: footer line to give
this credit.
He is recorded as author of that change. Only the first and last
Am Dienstag, 7. Oktober 2014, 10:35:24 schrieb Brad King:
Eike,
This fails on a few dashboard machines:
http://open.cdash.org/testDetails.php?test=286158250build=3519076
CMake Error at /.../Modules/FindThreads.cmake:207 (add_library):
add_library cannot create imported target
Brad King wrote:
On 10/03/2014 12:47 PM, Rolf Eike Beer wrote:
+ # give an exact match if the first ${NAME}_FIND_VERSION_COUNT
components of the version string match + # this constructs the
equivalent of (([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}}) +
unset
find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most
cases this behavior is not the one that one would expect or need. Most people
would instead allow any 2.0.x version to match. This sort of selection is
currently impossible without additional effort in every Find*.cmake
Am Freitag, 3. Oktober 2014, 08:41:47 schrieb Brad King:
On 10/03/2014 03:35 AM, Rolf Eike Beer wrote:
find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In
most cases this behavior is not the one that one would expect or need.
Most people would instead allow any 2.0.x
Brad King wrote:
On 10/01/2014 07:46 PM, Aleix Pol wrote:
I'm very interested in getting this in and iterating forward.
Any comments? How do changes get integrated?
My main concern is that the format has not been proven with a
corresponding implementation of an actual IDE/plugin to use
Brad King wrote:
On 10/03/2014 08:43 AM, Rolf Eike Beer wrote:
I think FPHSA could be changed to implement the expected behavior for
EXACT
If it is acceptable to change FPHSA in that way I can just go for it.
Yes, please try it.
It looks like this line is the culprit
Brad King wrote:
On 10/03/2014 11:53 AM, Rolf Eike Beer wrote:
It looks like this line is the culprit:
if (NOT ${${_NAME}_FIND_VERSION} VERSION_EQUAL ${VERSION})
I can solve this in CMake language, but the question is again if it may be
worth solving in the command itself? Meanwhile
Am Freitag, 3. Oktober 2014, 14:34:38 schrieb Brad King:
On 10/03/2014 12:47 PM, Rolf Eike Beer wrote:
+ # give an exact match if the first ${NAME}_FIND_VERSION_COUNT
components of the version string match + # this constructs the
equivalent of (([^.]\\.){${${_NAME
Am Freitag, 3. Oktober 2014, 15:02:42 schrieb Brad King:
Eike,
The topic adds a macro to FindThreads:
+macro(check_threads_lib LIBNAME FUNCNAME VARNAME)
Since it is not meant for public use, please name it something
like _threads_check_lib.
Will do.
signature.asc
Description: This is a
Richard Shaw wrote:
On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak malak.j...@gmail.com
wrote:
I did a several fixes to CMake related to Open Watcom which were
accepteed
to current development
branch a few month ago.
Up to now they were not included to official version 3.0 branch.
What I must
Am 29.08.2014 17:35, schrieb Bill Hoffman:
On 8/29/2014 9:47 AM, Bach, Pascal wrote:
Hi Everybody
I'm interested in cross compilation, and am already using it
extensively for Linux and Embedded Linux.
But now I ran into some problems cross compiling for Windows Compact
Embedded 2013 using
Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins:
Back on topic...
Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build failures, 4 test failures
Solaris 10 + GCC (from OpenCSW)
http://open.cdash.org/buildSummary.php?buildid=3470687
Am Samstag, 30. August 2014, 15:36:04 schrieb dev:
On August 30, 2014 at 1:04 PM Nils Gladitz nilsglad...@gmail.com
wrote:
On 30.08.2014 17:20, dev wrote:
So some time ago I tried, over and over, to get cmake to build on a
Solaris server and needless to say it was a fairly frustrating
Am Samstag, 30. August 2014, 16:00:34 schrieben Sie:
I need cmake to build cmake ? You mean there is no way to bootstrap
cmake with just a compiler and a good solid basic UNIX system ?
really ?
No, you need CMake to run the dashboard. There is a bootstrap script,
but you
Roger Leigh wrote:
On Sun, Aug 17, 2014 at 05:22:38PM +0100, Roger Leigh wrote:
On Sun, Aug 17, 2014 at 05:50:58PM +0200, Rolf Eike Beer wrote:
Am Sonntag, 17. August 2014, 16:21:24 schrieb Roger Leigh:
On Fri, Aug 15, 2014 at 12:31:17AM +0100, Roger Leigh wrote:
OK. I'll have
Am Dienstag, 19. August 2014, 23:29:13 schrieb Roger Leigh:
On Sun, Aug 17, 2014 at 03:43:46PM +0100, Roger Leigh wrote:
On Sun, Aug 17, 2014 at 03:46:14PM +0200, Rolf Eike Beer wrote:
Sorry for the naïve question, but the find_package docs also mentions
setting package_VERSION_COUNT
Chuck Atkins wrote:
Updated to allow for static and shared libs (yes, you can use shared libs
on a cray). The expectation is that your toolchain file will have the
appropriate logic to deal with this. Something like:
set(CMAKE_SYSTEM_NAME ComputeNodeLinux)
...
if(DEFINED
Roger Leigh wrote:
Dear Chuck,
Thanks for looking at this. Please find attached a new copy of the
patch which should address all your points. If you would like any
further changes making, please just let me know.
I don't think you need the functions for anything, especially not
Sorry for the naïve question, but the find_package docs also mentions
setting package_VERSION_COUNT but I don't see any examples of this in
cmake git. Is setting the MAJOR/MINOR/PATCH versions here correct or
redundant or plain wrong? Or all handled internally by
Am Sonntag, 17. August 2014, 16:21:24 schrieb Roger Leigh:
On Fri, Aug 15, 2014 at 12:31:17AM +0100, Roger Leigh wrote:
OK. I'll have to read up on this and see what needs doing.
In the meantime, I've attached a revised patch with all the
above corrections included.
Based on the
Am 23.07.2014 16:43, schrieb Brad King:
On 07/23/2014 08:16 AM, David Cole wrote:
Thanks to Daniel, great work on this contribution... This is a ton of
tedious work, but it will be very useful. Thank you *very much*.
+1
I've merged the topic to 'next' for testing, but without the CPack
or
Am 02.07.2014 15:19, schrieb Brad King:
On 07/01/2014 02:48 PM, Florent Castelli wrote:
When cross compiling, toolchains won't have install_name_tool,
which is provided by Xcode and command line tools on OSX.
This is a Mach-O specific utility and not required on all platforms.
Applied,
Am Montag, 9. Juni 2014, 10:00:35 schrieben Sie:
On 06/08/2014 09:12 AM, o.k...@gmx.de wrote:
I deleted the additional include/ in FindLua51.cmake and it worked.
I think that is the correct fix. I do not know why they were there
in the first place. They appear in FindLua50, FindLua51, and
Am 28.05.2014 10:39, schrieb Nils Gladitz:
As discussed here
http://www.cmake.org/pipermail/cmake/2014-May/057657.html
I proposed a minor modification in CMake that would allow shared
library targets to always be linked by -l/-L options rather than full
pathname on platforms which do not
Nils Gladitz wrote:
On 28.05.2014 20:15, Brad King wrote:
On 05/28/2014 12:17 PM, Nils Gladitz wrote:
In case you drop -Wl,-soname entirely ... how do you work around the
issue of the linker using paths rather than names in NEEDED entries?
Or does the issue not exist on OpenBSD?
This
Eric Berge wrote:
Compilation of cmake failed on HPUX (master as well as v2.8.12.2), at least
on my HPUX systems (uname info: B.11.31 U ia64 1105973567).
At least next is fine, and every patch master has been in next. So which
commit on master are you testing with?
Eike
--
signature.asc
Am Mittwoch, 21. Mai 2014, 09:24:34 schrieb Clinton Stimpson:
On Wednesday, May 21, 2014 10:50:42 AM Brad King wrote:
On 05/21/2014 09:18 AM, Stephen Kelly wrote:
I recall discussion about this kind of thing before, but I think
relating to qmake-qt4 and other versioned names.
Am 23.04.2014 09:33, schrieb Faraz Shahbazker:
Hi all,
I've been working on a generic cmake stub that allows libraries to be
built with multiple configuration options a.k.a. multilib support in
the style of GCC, on behalf of my employer. This feature allows a user
to build multiple versions of
Brad King wrote:
On 04/18/2014 03:07 AM, Rolf Eike Beer wrote:
what about nuking at least all
control characters and whitespace from variable names in 3.1? I don't
think
that anyone has used them on purpose, and accidentially using them will
only cause trouble.
If we're going
Am Sonntag, 13. April 2014, 07:05:27 schrieb Jiri Malak:
Hi,
I enclosed patch for removing placeholder x from STREQUAL operands.
It does comparision transparent.
I very much would like to see that, but there is a problem: CMake may
interpret the operands of STREQUAL both as text and as
Am Sonntag, 13. April 2014, 09:59:03 schrieb Jiri Malak:
I enclosed patch for removing placeholder x from STREQUAL operands.
It does comparision transparent.
I very much would like to see that, but there is a problem: CMake may
interpret the operands of STREQUAL both as text and as
Am 08.04.2014 11:43, schrieb Stephen Kelly:
Rolf Eike Beer wrote:
Of course, it is easier to get features into the
CMAKE_CXX_KNOWN_FEATURES
list when there is only one compiler to test for on the dashboard.
I'll
add one C++98 feature to establish the infrastructure, but I don't
intend
Am 10.04.2014 10:44, schrieb Stephen Kelly:
Rolf Eike Beer wrote:
Am 08.04.2014 11:43, schrieb Stephen Kelly:
Rolf Eike Beer wrote:
Of course, it is easier to get features into the
CMAKE_CXX_KNOWN_FEATURES
list when there is only one compiler to test for on the dashboard.
I'll
add one C++98
Daniele,
please have a look at these errors:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=3286713
Paths like /usr/local/* are not automatically included on that platform, maybe
that is the cause. I have more or less direct access to that machine during
normal working hours, so if you
Of course, it is easier to get features into the CMAKE_CXX_KNOWN_FEATURES
list when there is only one compiler to test for on the dashboard. I'll add
one C++98 feature to establish the infrastructure, but I don't intend to be
exhaustive about C++98 features. If you or anyone else has an
There is a report of a link problem with ncurses:
https://bugs.gentoo.org/show_bug.cgi?id=468622
I have no idea what's going on there, but maybe someone has a clue.
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Please keep messages
Am Freitag, 28. März 2014, 16:16:49 schrieb Stephen Kelly:
Hi,
The target_compile_features topic in my clone is almost ready to merge to
next.
Because I just had to look into the module: the stuff in
CMakeBackwardCompatibilityCXX.cmake could probably be merged (at least in
parts) into the
Am Sonntag, 23. Februar 2014, 09:13:18 schrieb Matthäus G. Chajdas:
Hi,
So, I'm very sorry to come up with those things now and not having catched
them earlier. If you now do
no problem, I should have also checked what I was adding with git :/
I think I fixed everything now in my
Am Samstag, 8. Februar 2014, 14:28:37 schrieb Matthäus G. Chajdas:
Hi,
I would like to propose two new modules for inclusion in CMake:
FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.)
FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is
basically the
Am Freitag, 21. Februar 2014, 14:51:19 schrieben Sie:
On Fri, Feb 21, 2014 at 14:18:02 -0500, Jean-Christophe Fillion-Robin wrote:
On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel
ben.boec...@kitware.comwrote:
I agree in general, however, my CMake style is to quote all variable
expansions
Are there any other corner cases I should consider banning as well? What
about behavior that should be allowed that currently isn't?
If this patch is the right place to address this is not clear to me, but I
mention them anyway.
-if a string is quoted, it may still be expanded as a variable
Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas:
Hi Eike,
thanks for reviewing! I've just pushed a new version, which should fix
all the issues you mentioned. I'm also setting now Hg_FOUND using
FOUND_VAR (this is also recommended in the documentation.)
Anything more
Am Sonntag, 16. Februar 2014, 20:26:22 schrieb Matthäus G. Chajdas:
Hi,
couldn't find it in the documentation either :(
Help/manual/cmake-developer.7.rst
I've changed it to OPENCL_VERSION_STRING.
Should be OpenCL_VERSION_STRING: the variables should follow the casing of the
module name.
Am Samstag, 15. Februar 2014, 18:54:47 schrieb Stephen Kelly:
Rolf Eike Beer wrote:
Matthäus G. Chajdas wrote:
Hi Eike,
all right, then Hg, as it's FindHg, unless there is a naming policy I'm
not aware of. I was just confused a bit due to FindGit, which uses GIT_
as the prefix
Am Samstag, 8. Februar 2014, 14:28:37 schrieb Matthäus G. Chajdas:
Hi,
I would like to propose two new modules for inclusion in CMake:
FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.)
FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is
basically the
Am Samstag, 8. Februar 2014, 16:38:02 schrieb Matthäus G. Chajdas:
Hi Eike,
thanks for taking a look. I've changed the module accordingly. Is there
a recommendation whether to use HG_ or Hg_ as the prefix for the variables?
As I guess there will be a bit back forth here, I've also pushed
Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf:
Hi,
on cmake stage I have a simple branch AddVersionToProjectCommand.
This extends the project command to also accept a version number:
project(Foo VERSION 1.2.3 CXX)
Cool, I like this. Shouldn't there be spaces on both sides
Am Montag, 6. Januar 2014, 23:26:49 schrieb Alexander Neundorf:
On Monday 06 January 2014, Rolf Eike Beer wrote:
Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf:
Hi,
on cmake stage I have a simple branch AddVersionToProjectCommand.
This extends the project command
Am 19.12.2013 16:28, schrieb Brad King:
On 12/11/2013 02:17 AM, Vadim Zhukov wrote:
It took a bit more thinking than I thought initially, sorrt. Anyway,
see the last update to find_backtrace topic. Worked fine for me.
I've rebased the new commit and merged the topic to 'next' for testing:
outro pessoa wrote:
If it can be fixed.
You are posting it to the wrong list (cmake-developers@) because it is no
CMake-internal failure. You are posting it to the wrong list (cmake@) because
it is nothing that CMake has done wrong. It is a code problem in traverso, so
post it there. And if
Am Freitag, 15. November 2013, 10:05:13 schrieb Nils Gladitz:
I would like to hijack/extend Stephen's changes in
05f5fde0eb83c0e49aab3214f28a098861aa3313
to also disallow target names that have been implicitly reserved by some
of the generators.
This list might not be complete but I assume
Am Dienstag, 22. Oktober 2013, 11:51:52 schrieb Pedro Navarro:
I would extend the regex in the DiffParser constructor to contain - at
the
end to make the propability that a filename with # in it would cause
issues
smaller. Also I find the usage of both Options and options in
Am Freitag, 18. Oktober 2013, 10:42:19 schrieb Brad King:
On 10/18/2013 10:20 AM, Daniele E. Domenichelli wrote:
Done and added a few more unit tests...
Thanks:
+if(x${arg} MATCHES ^x(BUILTIN_TYPES_ONLY)$ AND x${doing} MATCHES
^x$)
Generally the convention in similar state
Am 16.10.2013 17:03, schrieb Brad King:
On 10/16/2013 10:31 AM, Rolf Eike Beer wrote:
Time to clean next again like it was done after the automated CMake
style cleanup?
I've forgotten what we did that time around.
IIRC drop next, then recreate next as master, then let everyone merge
it's
Am Freitag, 11. Oktober 2013, 09:19:46 schrieb Brad King:
On 10/11/2013 02:16 AM, Rolf Eike Beer wrote:
Brad, this is one of your dashboard machines. I currently can't find the
mails where we discussed that. Can you please give Steven some
information about this?
Sorry, I have no idea
Brad King wrote:
* New policies to disable old commands that require significant
amounts of C++ code to be kept around just to support them.
These include (but may not be limited to):
- exec_program: replaced by execute_process
- export_library_dependencies: replaced by
Am Donnerstag, 10. Oktober 2013, 14:58:37 schrieb Brad King:
On 10/10/2013 12:57 PM, Brad King wrote:
On 10/10/2013 12:09 PM, Stephen Kelly wrote:
For example:
http://open.cdash.org/viewBuildError.php?buildid=3055146
It seems that machine is not processing the $TARGET_FILE genex. Any
Am Mittwoch, 9. Oktober 2013, 16:51:42 schrieb Stephen Kelly:
Brad King wrote:
Steve, Eike,
Now that 2.8.12 is tagged I'd like to revive the work to support
C++11 features.
I met Eike in person today at Qt DevDays and talked about this topic a bit.
The way forward is for me to get
Am Mittwoch, 9. Oktober 2013, 15:54:18 schrieb Brad King:
On 10/09/2013 12:21 PM, Rolf Eike Beer wrote:
One thing that is currently unclear if the simulated compiler id stuff
from Brad solves the problem of the Clang plugin running with gcc where
one would get the gcc version as compiler
Am Mittwoch, 2. Oktober 2013, 13:10:20 schrieb Pedro Navarro:
- It requires an English version of Perforce (use the P4_OPTIONS
variable, documented below to pass the -L switch to change the
message
language if you installation has a different one). It shouldn't be
too
outro pessoa wrote:
http://mail.kde.org/pipermail/kde-freebsd/2013-September/016064.html
I don't see how your topic and the link are related. The link shows that
the raptor includes are not installed or not found, which is an error
that traverso should catch in it's CMakeLists.txt.
Eike
--
Am 30.09.2013 16:45, schrieb Bill Hoffman:
On 9/28/2013 5:36 AM, Rolf Eike Beer wrote:
Break if everything is fine, continue on error or when no files are
found? All
other handlers support being run in parallel, why not Bullseye?
Not really.
Return 0 if COVFILE is not set so, no coverage
Am Sonntag, 29. September 2013, 14:22:02 schrieben Sie:
Eike,
This is fantastic feedback. Thanks!
I've responded to specific issues inline.
TL;DR: I fixed a lot of these points. This should be closer to
merge-ability.
Am Freitag, 27. September 2013, 11:30:52 schrieb Patrick Reynolds:
Am Donnerstag, 15. August 2013, 14:37:42 schrieb Stephen Kelly:
Stephen Kelly wrote:
Stephen Kelly wrote:
I still think you should revisit my review mail on point 2 too.
Something that becomes possible when thinking about the above and target
properties is interface requirements.
Am Montag, 16. September 2013, 21:58:08 schrieb clin...@elemtech.com:
Same here... and this looks like a regression:
A simple CMakeLists.txt like this can reproduce it.
set(CMAKE_BUILD_TYPE Debug)
find_package(HDF5 COMPONENTS C HL REQUIRED)
add_executable(foo foo.cpp)
Brad King wrote:
On 08/16/2013 09:47 AM, Brad King wrote:
The output that is used for matching against the regex *does*
have the valgrind == lines at the *end* but for some reason
they are not reported in DynamicAnalysis.xml. This should fix
the test:
Am Dienstag, 10. September 2013, 16:08:43 schrieb Robert Maynard:
The CMake 2.8.12 release candidate stream continues!
This is the last RC unless a critical, must-fix issue is found.
You can find the source and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D
Does bug 14398 count as
Brad King wrote:
On 08/14/2013 09:12 AM, Rolf Eike Beer wrote:
The memcheck output is at the beginning at the output, but the test is
only matching against the end, i.e. it ignores everything trailing. Or
does valgrind add trailing newlines there?
I cannot reproduce this even by running
Am 16.08.2013 14:53, schrieb Brad King:
On 08/16/2013 02:16 AM, Rolf Eike Beer wrote:
Seems still broken:
CTestTestMemcheckDummyPurify
(http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977909)
CTestTestMemcheckDummyValgrind
(http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977910
Am 16.08.2013 16:02, schrieb Brad King:
On 08/16/2013 09:47 AM, Brad King wrote:
Now I'll separately investigate why the output used for matching
and the output reported are not the same.
It is due to a feature added here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3017259a
to move
Am 14.08.2013 08:12, schrieb Rolf Eike Beer:
s...@rogue-research.com wrote:
http://open.cdash.org/testDetails.php?test=201937829build=2986379
(MacOS 10.8)
shows 3.4.0. But since even 3.4 does not seem to be released I
wonder
what's
going on there?
That one is the open source clang, which
Am Donnerstag, 15. August 2013, 15:23:05 schrieb Brad King:
On 08/14/2013 09:12 AM, Rolf Eike Beer wrote:
The memcheck output is at the beginning at the output, but the test is
only matching against the end, i.e. it ignores everything trailing. Or
does valgrind add trailing newlines
s...@rogue-research.com wrote:
http://open.cdash.org/testDetails.php?test=201937829build=2986379
(MacOS 10.8)
shows 3.4.0. But since even 3.4 does not seem to be released I wonder
what's
going on there?
That one is the open source clang, which I build from svn. It's not from
Am 14.08.2013 14:58, schrieb Brad King:
On 08/13/2013 05:30 PM, Rolf Eike Beer wrote:
*Dynamic analysis tests failing or not run*
CTestTestMemcheckDummyPurify
(http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977143)
CTestTestMemcheckDummyValgrind
(http://open.cdash.org
Am Mittwoch, 14. August 2013, 14:02:35 schrieb Brad King:
On 08/13/2013 01:54 PM, Rolf Eike Beer wrote:
Brad King wrote:
On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9.
I'll switch that over to use CMAKE_CXX_COMPILER_VERSION as suggested
below, the error
Brad King wrote:
On 08/02/2013 05:20 PM, Rolf Eike Beer wrote:
Brad, please don't merge that
Do all of the remaining test failures need the cxx-flags topic to fix?
No, since both are in next already everything that still shows up as a bug is
a bug.
http://open.cdash.org/testSummary.php
*Dynamic analysis tests failing or not run*
CTestTestMemcheckDummyPurify
(http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977143)
CTestTestMemcheckDummyValgrind
(http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977144)
CTestTestMemcheckDummyValgrindIgnoreMemcheck
Brad King wrote:
On 08/01/2013 04:47 PM, Rolf Eike Beer wrote:
Alexander Neundorf wrote:
I'm not sure I would have made this a find-module, instead of a
simple
module which can be included and then provides a function, but I
think this
doesn't matter much.
Because I get things like
Brad King wrote:
On 08/02/2013 05:20 PM, Rolf Eike Beer wrote:
Brad, please don't merge that next week
Okay. We're preparing 2.8.12 rc1 this week so I think we'll
hold off CXXFeatures until after 2.8.12 anyway.
I have pushed a fix for 14303 to next. Please have a look. Without
101 - 200 of 377 matches
Mail list logo
