Re: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
On 07/31/2015 07:14 AM, Radovan Bast wrote: the cmake-3.3.0-Linux-x86_64.tar.gz on http://www.cmake.org/download/ is not gzipped. Yes, it is. From a shell on the hosting server: $ file cmake-3.3.0-Linux-x86_64.tar.gz cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed cmake-3.3.0-Linux-x86_64.tar.gz I think some browsers or other download tools may automatically gunzip files during download. -Brad -- 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-developers] [patch] Export template instantiations with GenerateExportHeader
On 07/30/2015 05:17 PM, Roger Leigh wrote: Are the duplicated template exports here at the level of the translation unit not elided when linking the DLL? In the dlltest git repo, I specifically create DLLs with duplicate template exports in different translation units to make sure it doesn't error out, and it appears to cope. I haven't checked on whether it removed duplicates from the linked objects though--is this even possible? I thought all current toolchains were able to eliminate duplicate instantiations, or else you'd have massive explosions of duplicate templates common across all translation units. Given the backwardness of the Windows linker, it wouldn't surprise me if it were true though... I'm not an expert on the MS linker, but at least some toolchains treat implicit template instantiations as weak (W) symbols and explicit template instantiations as normal (T) symbols. Linkers will resolve duplicate W symbols but allow only one T symbol. Regardless, it is inefficient to ask the compiler to repeatedly do an explicit instantiation when only one is needed. I've seen projects that keep each explicit instantiation in a dedicated translation unit so that when one .o is needed for its instantiation it doesn't force bringing in a bunch of other instantiations from the same object. With the instantiate-in-header approach then all the objects in your library will instantiate all the templates whose headers they include. If the header always does the extern explicit instantiation then the compiler does not need to do the instantiation in any of the objects except the dedicated one. -Brad -- 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-developers] Linked library paths
On 07/30/2015 11:59 AM, Aleix Pol wrote: I need to get the linked libraries of a target. I was moving the code away from get_target_property to generator expressions that should get into a generated file, although I haven't managed yet. Is there any possibility to do that already? I've been thinking of adding something like a map function, so we can turn the target name we get from INTERFACE_LINK_LIBRARIES into a path, using the LOCATION property. Would that make sense? It is not possible to get this information during the configuration phase. The LOCATION property is not allowed since CMP0026 for a project's own targets. Otherwise, is it possible to properly get a function called right before cmake generation? No CMake language code can be executed during generation. That is the domain of generator expressions. It may be possible to add a genex to provide the needed info (e.g. through file(GENERATE)). What is your use case? -Brad -- 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-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
On 07/31/2015 03:09 PM, Brad King wrote: I think some browsers or other download tools may automatically gunzip files during download. I seem to get that with Chromium too. The HTTP response for cmake-3.3.0.tar.gz does contain: Content-Encoding: x-gzip Which I think does tell clients that they should decompress to get the actual content which is declared to be of Content-Type:application/x-gzip; this is I think incorrect unless the HTTP server compresses the .tar.gz once more with gzip before delivery. For cmake-3.3.0.zip of Content-Type: application/zip there is no Content-Encoding field in the HTTP response. Maybe other clients have workarounds for these kinds of errors? Nils -- 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-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
thanks Brad! interesting. sorry for the noise. best wishes, radovan On Fri, Jul 31, 2015 at 3:09 PM Brad King brad.k...@kitware.com wrote: On 07/31/2015 07:14 AM, Radovan Bast wrote: the cmake-3.3.0-Linux-x86_64.tar.gz on http://www.cmake.org/download/ is not gzipped. Yes, it is. From a shell on the hosting server: $ file cmake-3.3.0-Linux-x86_64.tar.gz cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed cmake-3.3.0-Linux-x86_64.tar.gz I think some browsers or other download tools may automatically gunzip files during download. -Brad -- 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-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
On Thursday 30 July 2015 09:28:12 Brad King wrote: On 07/29/2015 03:58 PM, Alex Merry wrote: This is intended to be used from a settings file which is applied to a group of CMake projects. This allows the file to control which policies means that users of the settings file are not forced to use NO_POLICY_SCOPE (particularly important if the settings file did not originally have any policy settings in it, but later acquired some). Policies should not be set from a central hub, especially without the explicit permission of the including project (via NO_POLICY_SCOPE). Setting policies centrally breaks their compatibility model. The whole point is that the old behavior is preserved (possibly with a warning) until the project whose code triggers the policy is modified to address it. By setting a policy on behalf of the project calling include() you could silence warnings about behavior changes or even introduce errors. Each project author needs a chance to see their own policy warnings and address them accordingly. I should perhaps explain our use case: KDE provides the module KDECompilerSettings, which set a bunch of default compiler settings we think are generally useful for KDE software projects (extra warnings, feature macros for libraries and so on). One of those settings is the compiler visibility stuff (CMAKE_CXX_VISIBILITY_PRESET is set to hidden and CMAKE_VISIBILITY_INLINES_HIDDEN is set to 1). CMP0063 now causes a whole bunch of warnings to appear across a load of projects where there are executable targets. These warnings are because of a setting in the KDECompilerSettings, so it is natual to want to resolve the issue there. We'd like to set the policy to NEW, because the new behaviour is sensible, and we'd consider any project that was broken by the change to already to be in need of fixing, because relying on the old behaviour is non-portable (due to DLL export behaviour). We'd rather have a hard error (even at build time instead of configure time) with a vanishingly small number of projects (hopefully none) than a warning on lots of projects that are almost certainly not affected. Now, sure, we could change every single project that includes this module to use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we tell people to use this module, it seems a very clunky approach. It means the module is at risk of leaking policy settings it didn't mean to (if it were to set policies for its own internal use), but it also means that, conceptually, you are asking users to opt-in to this particular behavoural change (because it happens to be implemented as a policy), but not to the other behavioural changes we make in the module (because they are implemented with variables). Of course, ideally, we'd like to policy change to have the same scope as the variable settings it accompanies. That doesn't seem to be possible to acheive, though (at least, not in a clean way) because of the separate stacks for policy scopes and variable scopes. Alex -- 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-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
Indeed a Chrome version that I have installed today does that to my surprise. Auto-unpacks during download but keeps the suffix. I would like to ask why but this is not the right list :-) Thanks again for the clarification! radovan On Fri, Jul 31, 2015 at 3:11 PM Radovan Bast radovan.b...@gmail.com wrote: thanks Brad! interesting. sorry for the noise. best wishes, radovan On Fri, Jul 31, 2015 at 3:09 PM Brad King brad.k...@kitware.com wrote: On 07/31/2015 07:14 AM, Radovan Bast wrote: the cmake-3.3.0-Linux-x86_64.tar.gz on http://www.cmake.org/download/ is not gzipped. Yes, it is. From a shell on the hosting server: $ file cmake-3.3.0-Linux-x86_64.tar.gz cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed cmake-3.3.0-Linux-x86_64.tar.gz I think some browsers or other download tools may automatically gunzip files during download. -Brad -- 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-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument
On 07/31/2015 12:54 PM, Alex Merry wrote: Setting policies centrally breaks their compatibility model. I should perhaps explain our use case: My assertion stands regardless of the use case. Now, sure, we could change every single project that includes this module to use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we tell people to use this module, it seems a very clunky approach. That is the correct approach. If a project wants to opt-in to letting KDECompilerSettings set policies for it (and therefore accept the risk of the broken compatibility model) then it should state so explicitly by including the module with NO_POLICY_SCOPE. It means the module is at risk of leaking policy settings it didn't mean to Use cmake_policy(PUSH/POP) around most of the module. Then set policies explicitly outside of that scope if they are intended to be set for includers that use NO_POLICY_SCOPE. you are asking users to opt-in to this particular behavoural change Yes, because the behavior change comes from a CMake version update. The purpose of policies is to not change behavior for a project until it is modified to be aware of the CMake version that makes the change. For this compatibility model to work the modification must be made in the project itself, not in one of its dependencies. -Brad -- 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-developers] Java support
OK. New version of patches. There is now a component per extra tool (for now IdlJ and JarSigner as suggested by Brad) to ensure future extensibility. Marc On 30/07/15 16:49, Brad King brad.k...@kitware.com wrote: On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote: here is the correct version. Thanks. The component name Extra sounds too generic and we won't be able to extend it in the future with other extra parts for the same reason these tools could not be made part of Development. Perhaps instead we should have components named IdlJ and JarSigner that applications can use to enforce that they are found. Thanks, -Brad 0001-Add-support-for-idlj-and-jarsigner-tools.patch Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch 0002-add_jar-now-supports-file-syntax-for-sources.patch Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch Description: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch 0004-Add-support-for-javah-tool.patch Description: 0004-Add-support-for-javah-tool.patch -- 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-developers] [PATCH 3/3] FindQt4: document cross compilation
Am 30.07.2015 um 17:20 schrieb Clinton Stimpson: On Thursday, July 30, 2015 10:56:02 AM Brad King wrote: On 07/30/2015 09:29 AM, Pascal Bach wrote: CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support something like NATIVE and TARGET that one could use to choose where to look for files. This way every find_* call could explicitly tell if it wants a host or a target version. Are you proposing new keyword arguments to find_* commands to specify this? The problem is that find modules don't necessarily know which kind of binary the application wants. That is why we have the CMAKE_FIND_ROOT_PATH_MODE_type variables. The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been sufficient for most packages for a long time. We regularly get complaints that FindPythonLibs does not ask the python executable where to get its libraries, and our answer every time is that it is wrong to do that for cross compiling. FindQt4 is making that mistake, and that is the cause of these troubles. FindQt4 should be taught not to ask qmake for anything when cross compiling. FindQt4 supports 2 use cases when cross compiling. 1. One Qt installation with a mix of native and non-native files. 2. Two Qt installations, one native and one non-native. In this case, qmake may still be queried to find other tools, but CMAKE_FIND_ROOT_PATH is used to find the non-native includes and libraries. The second case is what you are asking for, right? Yes case 2 is exactly what Yocto does, one qt-native and one qt-target. There might also be a third installation from the host machine (installed via apt-get for example). I need to check if I can modify FindQt4 to not use qmake for libary and header finding if CROSS_COMPILING is set. But just rely on plain find_* commands. This why I previously suggested changing from SET(CMAKE_FIND_ROOT_PATH /sysroot/arm ...) to SET(CMAKE_FIND_ROOT_PATH /sysroot/arm/usr ...) I could not get this to work. It seems that the variables returned by qmake take priority over everything else. Pascal Because its a find root, not a sysroot. -- 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
[cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
dear all, the cmake-3.3.0-Linux-x86_64.tar.gz on http://www.cmake.org/download/ is not gzipped. this confused me a bit since tar xvzf complained. of course it can be extracted still but i think it would be good to replace it by the compressed one. thank you and best wishes, radovan -- 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
