Re: [cmake-developers] Making kwsys a proper library
Honestly, KWSys has always seemed like a boost-avoidance mechanism from an outsider's perspective. Perhaps it should be replaced with boost equivalents in projects that need to be packaged for Fedora. I assume all the boost libraries are already packaged/available. Fuel for the fire, ;-) D On Fri, Aug 21, 2015 at 9:27 AM, Brad King brad.k...@kitware.com wrote: On 08/20/2015 10:19 PM, Orion Poplawski wrote: The consensus of the FPC is that the current situation with KWSys is very undesirable. While this approach may have been reasonable years ago with few consumers, it does not seem acceptable at this point. FWIW, the origin of this is the following: Many, many projects have their own custom code for many of the things KWSys is doing, but they may not organize the implementations into a distinguishable library. This does not seem to be a problem for packaging these projects even though they could be using third-party libraries instead. We have several projects that all want some of these things as details of their implementation but we do not want to maintain a first-class library for them. We could have had divergent implementations in each project like so many other unrelated projects do, but instead we decided to build infrastructure to share the common components of the source tree. This gives our projects the benefits of common, well- tested infrastructure without the cost of maintaining a public-facing library for them. If these implementations were not shared under the common KWSys banner then no one would have noticed that the projects appear to bundle a library. How is this worse than other projects that do not share code at all? Yes, several components of KWSys appear to re-implement functionality that is now available in better third-party libraries. However, much of it was added to our projects before those third-party libraries existed. Things like the RegularExpression component came from other third-parties at the time who were also not providing first-class libraries for them. Now they are kept in KWSys as a way to share the implementations among our projects at the source level. Any and all efforts by the KWSys maintainers to split out KWSys into proper libraries and perhaps pull out code that is only use by a single project into that project would be greatly appreciated. Some components of KWSys are present for historical reasons and can be factored out or removed now. This will be a worthwhile cleanup regardless of the above discussion. be greatly appreciated if KWSys using projects would include in their tarballs only those components that they actually used. Prior to CastXML, KWSys has only been included in projects that are much, much larger than itself and use most of its components so its size has not stood out before. I've now reduced the KWSys sources inside CastXML to the minimum it needs. Further discussion on the CastXML side would be better held on its own mailing list. -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 -- 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] Making kwsys a proper library
On 08/20/2015 10:19 PM, Orion Poplawski wrote: The consensus of the FPC is that the current situation with KWSys is very undesirable. While this approach may have been reasonable years ago with few consumers, it does not seem acceptable at this point. FWIW, the origin of this is the following: Many, many projects have their own custom code for many of the things KWSys is doing, but they may not organize the implementations into a distinguishable library. This does not seem to be a problem for packaging these projects even though they could be using third-party libraries instead. We have several projects that all want some of these things as details of their implementation but we do not want to maintain a first-class library for them. We could have had divergent implementations in each project like so many other unrelated projects do, but instead we decided to build infrastructure to share the common components of the source tree. This gives our projects the benefits of common, well- tested infrastructure without the cost of maintaining a public-facing library for them. If these implementations were not shared under the common KWSys banner then no one would have noticed that the projects appear to bundle a library. How is this worse than other projects that do not share code at all? Yes, several components of KWSys appear to re-implement functionality that is now available in better third-party libraries. However, much of it was added to our projects before those third-party libraries existed. Things like the RegularExpression component came from other third-parties at the time who were also not providing first-class libraries for them. Now they are kept in KWSys as a way to share the implementations among our projects at the source level. Any and all efforts by the KWSys maintainers to split out KWSys into proper libraries and perhaps pull out code that is only use by a single project into that project would be greatly appreciated. Some components of KWSys are present for historical reasons and can be factored out or removed now. This will be a worthwhile cleanup regardless of the above discussion. be greatly appreciated if KWSys using projects would include in their tarballs only those components that they actually used. Prior to CastXML, KWSys has only been included in projects that are much, much larger than itself and use most of its components so its size has not stood out before. I've now reduced the KWSys sources inside CastXML to the minimum it needs. Further discussion on the CastXML side would be better held on its own mailing list. -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 0015669]: XCTest for iOS target has incorrect TEST_HOST
On 08/19/2015 03:46 PM, Gregor Jasny via cmake-developers wrote: The problem I see with this approach is that CMake provides no official iOS toolchain file (maybe we should?). And the popular cmake-ios project [1] for example sets SYSTEM_NAME to Darwin. Yes. This should be resolved by splitting the proper pieces of such toolchain files out into a Modules/Platform/iOS.cmake file. I'm not familiar enough with iOS development to do this though. Maybe we can detect iOS via SDK string for now. Okay. I pushed the ios-app-bundle-layout topic branch together with a test case. Thanks. I merged to 'next' for testing last night. Please take a look at the failures: https://open.cdash.org/testSummary.php?project=1name=RunCMake.XcodeProjectdate=2015-08-21 Thanks, -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
On 08/18/2015 02:57 AM, CHEVRIER, Marc wrote: Unfortunately I don't have access to an HP-UX system. For reference, we worked out the problem off-list with someone that has access to HP-UX. The fix is: HP-UX: Do not use .sl extension for shared libs on Itanium http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=625225bb I've rebased the java topic on a version containing the fix: UseJava: Add support for javah tool http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4476feac There is still one failure on the dashboard but I think it is related to the way the run is configured rather than a problem with the source. Once I've worked that out I'll report back. -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] Making kwsys a proper library
On 08/21/2015 10:58 AM, Ben Boeckel wrote: CMake would have to ship with multiple versions of Boost, each subsetted and likely patched. That is hardly better. This falls under the category of third-party libraries that are candidates for use in the already-proposed cleanup of KWSys: On 08/21/2015 09:27 AM, Brad King wrote: Some components of KWSys are present for historical reasons and can be factored out or removed now. This will be a worthwhile cleanup regardless of the above discussion. Some of the dependents may need to find alternatives as part of this cleanup, but selections will need to be made on a per-case basis. -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] Making kwsys a proper library
On Fri, Aug 21, 2015 at 10:35:58 -0400, David Cole via cmake-developers wrote: Honestly, KWSys has always seemed like a boost-avoidance mechanism from an outsider's perspective. Perhaps it should be replaced with boost equivalents in projects that need to be packaged for Fedora. I assume all the boost libraries are already packaged/available. While I do love me some Boost, it doesn't provide process launching APIs, so you'd still need to handle that. Plus, Boost's lack of a stable API/ABI across the large range of versions that would need to be supported (e.g., there is no Boost release which supports VS7.1 and VS2015 at the same time, nevermind some of the more obscure compilers CMake expects to self-host on). And you'd need to both support filesystem2 and filesystem3 in client code, so it's not just a problem at the get boost building level. IMO, it would be *much* worse since CMake would have to ship with multiple versions of Boost, each subsetted and likely patched. That is hardly better. --Ben -- 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] ExternalProject: Use native paths as substitute for directory tokens
What do you think about the new patch I attached to this mail? It adds an option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake script file which tests/shows this feature. Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David Cole via cmake-developers [cmake-developers@cmake.org] Gesendet: Donnerstag, 20. August 2015 23:20 An: James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. David C. On Thu, Aug 20, 2015 at 2:58 PM, James Johnston johnstonj.pub...@codenest.com wrote: Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also concerned about. I still think your original method of building Boost is a bit unusual and would be better served by _Add_Step with a custom working directory - because that's the publicly documented/standard way of changing the working directory, but that is up to you. :) Best regards, James Johnston On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy s.kislins...@dkfz-heidelberg.de wrote Hi, thank you for our suggestions. I am aware that I can solve my example differently and that it might look not directly connected the proposal, but well, it is an example just to show a single case and why it matters. :) I did not want to discuss the example itself. Working around here would just resolve a symptom. My point is the overall problem that would persist: A big part of ExternalProject is to issue commands for predefined and custom steps. Those commands are supposed to be executed by the shell/command line. According to the documentation and the source code of ExternalProject, directory tokens are mainly supposed to be replaced in commands. It is my understanding, that it is a bug, if CMake isn't able to assemble these commands correctly. This would include usage of the correct path style of the OS for shell/command line commands. As directory tokens are replaced internally right before a shell/command line command is assembled, I can't see why this would be kind of API-breaking. You cannot interfere in your CMake code with these internal replacements. Therefore I would still prefer my solution as it is pretty simple without adding even more features to ExternalProject and in my opinion without breaking code in the wild. It is a true bug fix instead of a feature request for working directories, which is a different topic that just coincidentally arised because of my specific example I guess. The features you described wouldn't fix the actual bug. As you were not sure if my approach would even fix my problems: It does of course and this is what I am currently doing and what I tested extensively before creating the patch. :) Regarding your quote from the add_custom_command documentation I can tell you
[cmake-developers] PATCH: Add Certificate Thumbprint to VS for Windows Phone and Windows Store projects
I would like to submit a new patch to write the PackageCertificateThumbprint tag in VS projects for Windows Phone and Windows Store projects. When creating a Windows Store project, a certificate is added to the package. There is a PackageCertificateThumbprint tag that VS will write when absent that contains the thumbprint of the associated certificate. This change tries to extract the thumbprint from the specified certificate and add the tag to the project when it can be extracted. This enables easier automated builds that do not run through the VS GUI. The change is pretty straightforward, we try to load the specified certificate when present and extract the thumbprint using the Windows Crypto APIs and adds the tag at the same time as the PackageCertificate . This adds a new dependency to crypt32.lib which is available on all versions of Windows starting with Windows XP. CertThumb.patch Description: CertThumb.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
[cmake-developers] [CMake 0015707]: Error at: math(EXPR value -1 + 1)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15707 == Reported By:Daniel Levin Assigned To: == Project:CMake Issue ID: 15707 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-08-21 21:58 EDT Last Modified: 2015-08-21 21:58 EDT == Summary:Error at: math(EXPR value -1 + 1) Description: CMake cannot handle next expression: math(EXPR value -1 + 1) Error output: math cannot parse the expression: -1 + 1: syntax error, unexpected exp_MINUS, expecting exp_OPENPARENT or exp_NUMBER (1) == Issue History Date ModifiedUsername FieldChange == 2015-08-21 21:58 Daniel Levin New Issue == -- 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] ExternalProject: Use native paths as substitute for directory tokens
I still disagree on the point that CMake shouldn't be fixed because of possibly erroneous external scripts that are not able to handle paths which were - again possibly - passed to them as parameters in the style of the platform they were written for. This is very hypothetical in my opinion. We should also bring to mind here that CMake as seen as an entity as well as CMake scripts wouldn't be affected by the fix at all regarding backwards compatibility. How can these obviously rare cases - if existent at all - lie in the scope of responsibility of CMake? And how could one justify that everyone (else?) have to continue working around this bug? Please be aware that I am not asking that EVERYONE should solve a problem which I have encountered and that this is far from it just works. In fact, James Johnston even ran into trouble with this bug yesterday coincidentally and I know at least of colleagues working around this issue for years now. It just doesn't work and there is no way that one could know this without burning lifetime figuring out what's going on and how to work around. Referring to the latest email of James Johnston and your advice not to use directory tokens, you see, that this, on one hand, is not a good option sometimes (and this would ironically create potential to break backwards compatibility as one would need to maintain script that kind of mimics CMake internals). On the other hand it is a little strange as it is rather equivalent to to say not to use the feature for what is solely intended to at all. Obviously, something has to be done. The question seems to be: What should be done if you still want to keep the erroneous behavior? - Point out the issue in the documentation (and wish good luck to CMake users for future upgrades of CMake as they are potentially mimicking potentially changing internals instead)? :) - Adding a CMake policy? - Adding a new *single* binary option to ExternalProject_* functions in the style of the BUILD_IN_SOURCE 1 option, e.g. NATIVE_DIR_TOKENS? - Something else? I would still prefer to fix the bug directly as the only counter argument until now was about (loosely coupled) backwards compatibility and I hope I could show above that actually the reverse is true, and there is an on-going (loosely coupled) backwards compatibility issue. Stefan Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David Cole via cmake-developers [cmake-developers@cmake.org] Gesendet: Donnerstag, 20. August 2015 23:20 An: James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. David C. On Thu, Aug 20, 2015 at 2:58 PM, James Johnston johnstonj.pub...@codenest.com wrote: Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also concerned about. I still think your original method of building Boost is a bit unusual and
