Re: [cmake-developers] Suspicious Clang versions
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 I build from svn. It's not from Xcode. It's my 'bleeding edge' build machine. clang is always getting stricter and getting new warnings, so this help us fix them before a CMake/VTK/ITK release. Ok, then I assume that this is complaining about something in my test files. Could you tell me what went wrong here, please? http://open.cdash.org/testDetails.php?test=203511533build=2997654 http://open.cdash.org/testDetails.php?test=203678570build=2998892 Looks like the headers are not those that belong to that version of Clang, but older ones. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
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.
I've implemented a prototype which has better API than your module.
In my concept:
* Applying the -std=c++11 flag is the responsibility of CMake, not the user.
* CMake determines the -std= flag to use (GCC 4.9 has -std=c++1y by now). It
won't add '-std=c++11 -std=c++14', but just '-std=c++14'
* Required compiler features are scoped to targets.
* Target properties are set, exported and transitively evaluated track the
compiler features required.
* Compiler requirements can be optional, in which case -D defines are
generated in the (PUBLIC) COMPILE_DEFINITIONS
* The -D defines are for scoping or replacement, depending on what the
feature calls for.
* Required compiler features are listed in the INTERFACE of exported
targets. CMake evaluates whether the compiler is capable of using the
IMPORTED targets it is supposed to use transitively, in a similar way to the
POSITION_INDEPENDENT_CODE feature.
* A new command target_compiler_feature is introduced with two signatures:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
* Another non-target-scoped command could be introduced, similar to
target_compile_options - add_compile_options.
This is better in many noteworthy ways to the cxx11 topic in the stage.
Brad, do you have any response to any part of anything I wrote about that
topic?
Thanks,
Steve.
#include foo.h
A::A(int i, void *p)
: num(i), ptr(p)
{
}
A::A(const A other)
: num(other.num), ptr(other.ptr)
{
}
A::~A()
{
}
A A::operator=(const A other)
{
num = other.num;
ptr = other.ptr;
return *this;
}
B::B(int i, void *p)
: A(i, ptr)
{
}
#include utility
templatetypename T
struct Factory
{
// Variadic templates and macros required to use this library by design. Not guarded by any macro.
templatetypename... Args
static T Create(Args... args) { return T(std::forwardArgs(args)...); }
};
#define CREATE(TYPE, ...) Factory TYPE ::Create(__VA_ARGS__)
class A
{
templatetypename friend class Factory;
friend class B;
int num;
void *ptr;
A(int i, void *p = Foo_NULLPTR);
public:
#if Foo_RVALUE_REFS
inline A(A other) : num(other.num), ptr(other.ptr)
{
other.num = 0;
other.ptr = 0;
}
inline A operator=(A other)
{
std::swap(num, other.num);
std::swap(ptr, other.ptr);
return *this;
}
#endif
inline A(const A other);
inline A operator=(const A other);
virtual ~A();
virtual void doSomething() {}
virtual void doSomethingElse() {}
};
class B : public A
{
templatetypename friend class Factory;
B(int i, void *ptr = Foo_NULLPTR);
public:
void doSomething() Foo_OVERRIDE {}
void doSomethingElse() Foo_FINAL {}
};
#include foo.h
int main(int argc, char **argv)
{
auto a = CREATE(A, 47, new long);
auto b = CREATE(B, 42);
}
# FIXME: Encode this stuff into Modules/Compiler/*.cmake
if(CMAKE_CXX_COMPILER_ID STREQUAL GNU)
set(CMAKE_C_COMPILER_FEATURES)
if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_C_COMPILER_FEATURES
variadic_macros
)
endif()
set(CMAKE_C99_STANDARD_COMPILE_OPTION -std=c99)
# FIXME: This feature listing is not complete.
set(CMAKE_CXX98_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX98_COMPILER_FEATURES
member_templates
template_template_parameters
template_friends
)
endif()
set(CMAKE_CXX11_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
decltype
rvalue_refs
static_assert
variadic_macros
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
auto_type
default_members
deleted_members
variadic_templates
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.6)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
nullptr
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
# binary_literals
generalized_lambda_capture
return_type_deduction
)
endif()
set(CMAKE_CXX_COMPILER_FEATURES
binary_literals
${CMAKE_CXX98_COMPILER_FEATURES}
${CMAKE_CXX11_COMPILER_FEATURES}
${CMAKE_CXX14_COMPILER_FEATURES}
)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
elseif(NOT CMAKE_CXX_COMPILER_VERSION
Re: [cmake-developers] Suspicious Clang versions
On Thu, 15 Aug 2013 10:15:11 +0200, Rolf Eike Beer said: http://open.cdash.org/testDetails.php?test=203678570build=2998892 Looks like the headers are not those that belong to that version of Clang, but older ones. To which headers do you refer? On that version of the OS and Xcode, I believe the default C++ library is libstdc++, not libc++; and it's a gcc 4.2 era libstd++, with limited C++11 support. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Fix a typo in documentation
From: Yury G. Kudryashov urkud.ur...@gmail.com --- Source/CPack/cmCPackDocumentVariables.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Source/CPack/cmCPackDocumentVariables.cxx b/Source/CPack/cmCPackDocumentVariables.cxx index 1dfaaf9..8b16ae9 100644 --- a/Source/CPack/cmCPackDocumentVariables.cxx +++ b/Source/CPack/cmCPackDocumentVariables.cxx @@ -28,7 +28,7 @@ void cmCPackDocumentVariables::DefineVariables(cmake* cm) the so-called top level directory. The purpose of is to include (set to 1 or ON or TRUE) the top level directory in the package or not (set to 0 or OFF or FALSE).\n - Each CPack generator as a built-in default value for this + Each CPack generator has a built-in default value for this variable. E.g. Archive generators (ZIP, TGZ, ...) includes the top level whereas RPM or DEB don't. The user may override the default value by setting this variable.\n -- 1.8.1.2 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix a typo in documentation
On 08/15/2013 12:13 PM, Yury G. Kudryashov wrote: From: Yury G. Kudryashov urkud.ur...@gmail.com --- Source/CPack/cmCPackDocumentVariables.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=807a564e -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CTestTestMemcheckDummy* failures during dynamic analysis
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 the tests under ctest -T Memcheck locally on the machine, but it is very consistent when running for the dashboard. Close inspection of the test output reported in the dashboard shows that there is a trailing \n\t added beyond the expected output. I've modified the regex to tolerate it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67e45711 -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CTestTestMemcheckDummy* failures during dynamic analysis
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 there? I cannot reproduce this even by running the tests under ctest -T Memcheck locally on the machine, but it is very consistent when running for the dashboard. Close inspection of the test output reported in the dashboard shows that there is a trailing \n\t added beyond the expected output. I've modified the regex to tolerate it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67e45711 Excellent, thanks. Pretty hard to spot on the website. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014361]: Please offer amd64 binary for Linux
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14361 == Reported By:Ma Xiaojun Assigned To: == Project:CMake Issue ID: 14361 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-08-16 01:44 EDT Last Modified: 2013-08-16 01:44 EDT == Summary:Please offer amd64 binary for Linux Description: http://www.cmake.org/cmake/resources/software.html just lists Linux i386. I believe that 64bit Linux is quite popular these days. == Issue History Date ModifiedUsername FieldChange == 2013-08-16 01:44 Ma Xiaojun New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
