[cmake-developers] Multiple fixup_bundle and cpack crash
Could anyone with appropriate knowledge of fixup_bundle internal have a look at this bug: http://public.kitware.com/Bug/view.php?id=12656 It may be windows specific. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] libarchive upstream
On 1/5/2012 10:05 AM, Rolf Eike Beer wrote: Please cherry-pick 41719b7507a70b0c098f652c96693ba7755b397f into the updated branch again and push this upstream, too. The libarchive-upstream branch must remain pristine w.r.t. upstream. Your fix is already in the update-libarchive topic: http://cmake.org/gitweb?p=cmake.git;a=commit;h=c37c0c78 There are several other fixes in the topic that should go upstream too. Some of them came from fixes to our previous libarchive snapshot and some of them are new. The new way to do the import (enabled by Git) will allow me to identify and extract all of them once the topic has matured. -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] libarchive upstream
> On 1/3/2012 4:48 PM, Eric Noulard wrote: >> 3.0.2 does include the feature: >> Dec 24, 2011: libarchive 3.0.2 released > > Great. I started the update work less than a week before that ;) > >> Let's wait for you to finish your experiment with 3.0.0-r3950 >> then may be the first application of your work may be the integration >> of 3.0.2 (or better depending on the work in-between). > > Sounds good. Please cherry-pick 41719b7507a70b0c098f652c96693ba7755b397f into the updated branch again and push this upstream, too. 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] CheckPrototypeDefinition concerns
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote: Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. The subject of this thing is to provoke a compile error if the prototype doesn't match. And it even introduced the symbol _itself_, so it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. [snip] But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. I've CCed Andreas, the author of CheckPrototypeDefinition. Andreas, please see the above concerns Eike has raised about the module implementation. Thanks, -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] CheckSymbolExists is unreliable
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote: Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. Okay. As you said the concerns with that one are another topic. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. Sounds good. Thanks, -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] CheckSymbolExists is unreliable
Brad King wrote: > Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it > has the same problem. I have looked into this and I don't think it has. The subject of this thing is to provoke a compile error if the prototype doesn't match. And it even introduced the symbol _itself_, so it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. So for me it looks like it could have the optimization problem, but that wouldn't be a problem here as the symbol itself is not what we are interested in at that point. But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. This one needs rework, too, but that should go into a separate topic. Opinions? 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
