[Cmake-commits] CMake branch, master, updated. v3.4.1-750-g630e444
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, master has been updated via 630e444e97df52d35a93d22c54359881c1e11193 (commit) from 554c3074556fb8fbf4918fc3e2ea3bef97add1ad (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=630e444e97df52d35a93d22c54359881c1e11193 commit 630e444e97df52d35a93d22c54359881c1e11193 Author: Kitware Robot <kwro...@kitware.com> AuthorDate: Fri Dec 25 00:01:06 2015 -0500 Commit: Kitware Robot <kwro...@kitware.com> CommitDate: Fri Dec 25 00:01:06 2015 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7c730e5..c8c71b5 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20151224) +set(CMake_VERSION_PATCH 20151225) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [CMake] Tests with assert and Release build type
On 24-Dec-15 19:46, Magnus Therning wrote: I'm *not* mixing stuff built with `-g` and stuff built without it. Actually I don't see anything bad about mixing `-g` code with code without `-g`. I'm also *not* mixing linking with debug- and non-debug libraries. Since we cover a lot of aspects please specify what you mean by debug and non-debug libraries. I'm only mixing stuff build with `-DNDEBUG` and stuff built without it. see below On 24-Dec-15 19:48, Magnus Therning wrote: Ruslan Baratov writes: On 22-Dec-15 04:07, Magnus Therning wrote: It is possible to hit situation when ODR will be violated, e.g. if somebody define optional member in structure with "#if defined(NDEBUG)" condition. Something like this: http://stackoverflow.com/questions/20833226/library-headers-and-define Yes, if we ever start using the NDEBUG macro to control anything in our code then I'll have to worry about this, as it stands right now it's only the `assert` from `assert.h` that cares about it. Even if you care only about `assert` somebody can define different type of structures based on value of NDEBUG. I'm talking about 3rd party library that you can use and you can't control. If this will lead to ODR violation then bug is NOT in 3rd party code, but in YOUR code. That's my point. You can mix c++11 with c++98, libc++ with libstdc++, mingw with cygwin, mingw with Visual Studio, NDEBUG with non NDEBUG, and it MAY works, but when something suddenly will stop working with very obscure errors that it's YOUR fault and not 3rd party.// If I'm reading you correctly you are advocating I simply get rid of the use of those asserts altogether instead. I'm not sure what you mean. I'm just telling that if you want do some runtime checks even when NDEBUG is OFF then you should introduce your own macro FOO_DEBUG. Difference is about global/local affects. Ruslo -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake 3.4.1 bootstrap compile error
I found that there is an install of gcc in /usr/local/ and this was causing the issue. once I removed that things went smoothly. On 12/23/2015 09:00 AM, Burlen Loring wrote: I tried to download and compile 3.4.1 on Apple 10.10.5. I did ./configure prefix=blah && make here is the error: g++ -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Source -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -c /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmFindProgramCommand.cxx:16, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx:52: /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before ‘^’ token typedef void (^dispatch_block_t)(void); ^ /usr/include/dispatch/object.h:143:15: error: expected ‘)’ before ‘^’ token /usr/include/dispatch/object.h:362:3: error: ‘dispatch_block_t’ has not been declared dispatch_block_t notification_block); ^ make: *** [cmBootstrapCommands1.o] Error 1 I guess that this is because homebrew installed gcc. All the same, shouldn't this just work? If Cmake can't work with homebrew gcc then should it ignore it? Burlen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] CMakeFindDependencyMacro limitations
Roger Leigh wrote: > On 21/12/2015 15:07, Stephen Kelly wrote: >> Roger Leigh wrote: >>> I can understand why REQUIRED and related >>> arguments are omitted--that is why find_dependency exists--but I'd quite >>> like to be able to specify COMPONENTS where needed e.g. with FindBoost, >>> and this is not currently possible. >> >> I don't remember whether this was discussed when designing >> find_dependency. Perhaps COMPONENTS could be added to the macro now. > > Currently, for my own needs, COMPONENTS is the single missing piece. If > it would be possible to add this, it would certainly be very useful. > > I'd be happy to provide a patch for COMPONENTS if you like. I think the reason that the macro does not support COMPONENTS is that I don't understand how COMPONENTS is supposed to work. For example: find_package(Qt5 COMPONENTS Widgets) # Is Qt5_FOUND set to true or false? find_package(Qt5 COMPONENTS Quick) # ... what about now? What does _FOUND ever mean if the find_package is called multiple times with different components? Does it mean anything? Should CMake disallow multiple use of find_package with the same package and with different components? If user code has find_package(Qt5 COMPONENTS Widgets) find_package(FooBar REQUIRED) and FooBarConfig.cmake has find_dependency(Qt5 COMPONENTS Quick) then the if(Qt5_FOUND) in the macro will mean it will not try to find the Quick component. So, there may be a need to establish a convention such as __FOUND and check that for each component in the macro. You would also need to think through everything and find out whether that is really a full solution. I haven't thought more deeply about it than the above. Note that the above example with Qt 5 can not currently happen in practice because the find_dependency macro does not support COMPONENTS, so config files must instead use find_dependency(Qt5Quick) if they want to use the macro currently. This is a good thing. So, I would like to know if * adding COMPONENTS support to the find_dependency macro is the right thing to do * or if the right thing to do is to move away from support for COMPONENTS generally because of its messy semantics * or if find_package should change to not support multiple calls for the same package. I really don't know the answer - I think someone needs to do deep thinking about it. I would prefer the macro not be changed before that deep thinking about COMPONENTS generally is done. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Tests with assert and Release build type
David Cole writes: > Not only is it possible ... it WILL happen if you use the Microsoft > C++ compiler and try to mix and match Release and Debug compilation > units. > > The MS compiler has some very nice memory tracking facilities built > into the Debug runtime libraries, but it is accomplished via different > structs for Debug and Release builds with extra stuff in the Debug > structs. > So allocations from a Debug compilation unit will not be accessed > correctly in a linked-in Release compilation unit when a pointer to it > is passed across the boundary. > > You will see access violations and hard crashes happening in builds > from the Microsoft compiler unless you ensure that everything in a > build has matching Debug/Release defines and compiler settings. > > It is only safe to mix-n-match if all calls which cross a boundary > between compilation units have NO differences in their struct and > class definitions from an ABI perspective. Since it is difficult to > verify when this is the case (in general) for large C++ projects, it's > best to avoid mixing and matching... I'm *not* mixing stuff built with `-g` and stuff built without it. I'm also *not* mixing linking with debug- and non-debug libraries. I'm only mixing stuff build with `-DNDEBUG` and stuff built without it. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Software isn't finished until the last user is dead. -- head on FLOSS Weekly signature.asc Description: PGP signature -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles
> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h) Quick addendum: Just realized the bridging header should probably be per-target. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Tests with assert and Release build type
Ruslan Baratov writes: > On 22-Dec-15 04:07, Magnus Therning wrote: >> Ruslan Baratov writes: >> >>> On 20-Dec-15 01:31, Magnus Therning wrote: Ruslan Baratov writes: > How about using RelWithDebInfo? See: > http://stackoverflow.com/a/28124715/2288008 Hmm, I'm probably missing something but how does that solve the issue with some targets requiring NDEBUG to be *undefined* and other targets requiring NDEBUG to be defined? >>> I don't think that building targets with different NDEBUG values is a >>> good idea. More correct approach will be to introduce custom macro to >>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). >> Why not? > It is possible to hit situation when ODR will be violated, e.g. if > somebody define optional member in structure with "#if defined(NDEBUG)" > condition. Something like this: > http://stackoverflow.com/questions/20833226/library-headers-and-define Yes, if we ever start using the NDEBUG macro to control anything in our code then I'll have to worry about this, as it stands right now it's only the `assert` from `assert.h` that cares about it. If I'm reading you correctly you are advocating I simply get rid of the use of those asserts altogether instead. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich signature.asc Description: PGP signature -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
