Re: [cmake-developers] Patch: cmjsoncpp - missing isfinite on AIX 5.1 and HP-UX 11.23
On 04/01/2015 05:43 AM, Ådne Hovda wrote: I think the suggested change should be pretty safe Yes, the commit I linked worked cleanly on nightly testing. I actually thought about setting up dashboard builds, mostly for my own convenience, but if it would be helpful for anyone else Having nightly testing helps us catch problems as soon as they are introduced. That makes release candidate cycles faster because we do not have to churn on breakage introduced on non-tested platforms. 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
[cmake-developers] [CMake 0015487]: Leading double slashes in path cause unparsable Xcode project
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15487 == Reported By:Gregor Jasny Assigned To: == Project:CMake Issue ID: 15487 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-01 12:21 EDT Last Modified: 2015-04-01 12:21 EDT == Summary:Leading double slashes in path cause unparsable Xcode project Description: If the project source path start with a double slash the resulting Xcode project cannot be parsed by Xcode. I got the double slash at the beginning because my build orchestration script tries to normalize the source path by calling pwd -P. So this: $ pwd /Volumes/Macintosh HD/Users/jasny/src/pathbug was translated into $ pwd -P //Users/jasny/src/pathbug and passed to cmake invocation. Multiple slashes are discussed here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash. I thought about adding a kind of normalization which replaces multiple slashes with one but I'm unsure if this should be done globally or just in the Xcode generator. I will also file a bug report with Apple. Steps to Reproduce: project(Foo CXX) add_library(foo STATIC foo.cpp) cmake -GXcode //path/to/source open Foo.xcodeproj Result: Project /Users/jasny/src/pathbug/build/Foo.xcodeproj cannot be opened because the project file cannot be parsed. == Issue History Date ModifiedUsername FieldChange == 2015-04-01 12:21 Gregor Jasny 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
[cmake-developers] [CMake 0015488]: Strange things happen to paths below /Volumes/Macintosh HD
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15488 == Reported By:Gregor Jasny Assigned To: == Project:CMake Issue ID: 15488 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2015-04-01 12:33 EDT Last Modified: 2015-04-01 12:33 EDT == Summary:Strange things happen to paths below /Volumes/Macintosh HD Description: Paths get extra /Volumes/Macintosh HD prepended Steps to Reproduce: On a Mac where the HDD is labeled Macintosh HD try the following: Create a Project: project(Foo CXX) add_library(foo STATIC foo.cpp) Create a build dir ad change into it. The pwd should look like this: /Volumes/Macintosh HD/Users/jasny/src/pathbug/build For Makefiles you get: [100%] Building CXX object CMakeFiles/foo.dir/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Users/jasny/src/pathbug/foo.cpp.o Linking CXX static library /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a(foo.cpp.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a(foo.cpp.o) has no symbols warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a the table of contents is empty (no object file members in the library define global symbols) [100%] Built target foo For Ninja: $ ninja -v [1/2] /Volumes/Macintosh HD/Volumes/Macintosh HD/usr/bin/c++ -MMD -MT CMakeFiles/foo.dir/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Users/jasny/src/pathbug/foo.cpp.o -MF CMakeFiles/foo.dir/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Users/jasny/src/pathbug/foo.cpp.o.d -o CMakeFiles/foo.dir/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Users/jasny/src/pathbug/foo.cpp.o -c '/Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/foo.cpp' [2/2] : /usr/local/Cellar/cmake/3.2.1/bin/cmake -E remove /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/usr/bin/ar cq /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a CMakeFiles/foo.dir/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Volumes/Macintosh_HD/Users/jasny/src/pathbug/foo.cpp.o /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/usr/bin/ranlib /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a : /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a(foo.cpp.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a(foo.cpp.o) has no symbols warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: /Volumes/Macintosh HD/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/jasny/src/pathbug/build/libfoo.a the table of contents is empty (no object file members in the library define global symbols) == Issue History Date ModifiedUsername FieldChange == 2015-04-01 12:33 Gregor Jasny New Issue
Re: [cmake-developers] Generating buildsystem metadata from CMake
On 01 Apr 2015, at 00:41, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete and cannot be used directly: * include directories list misses compiler-defined search paths CMake gathers those during configure time, and we can add them to the metadata too. However appealing it is, I don’t think it’s a good option, since it'll make generation phase way longer, since files and targets may have different command line options and CMake will need to call compiler for all of them. We’d rather do it lazily when times come to process the given file having specialized caches on IDE side. * quote include directories are not distinguishable CMake does not currently generate -iquote as a result of a user writing an include_directories() call. Are you asking for that as an option? That would be an independent feature request. I'd suggest filing it in the tracker. Otherwise, the only way CMake currently would pass such options to the compiler is if the user specified them in CMAKE_CXX_FLAGS or add_compile_options() or similar. Yes, I mean that user may easily have -iquote directly passed as command line option and the IDE need to know that. CMake does not attempt to parse CMAKE_CXX_FLAGS for things which look like include directories. That variable is just an opaque string of data from the point of view of CMake. It is not clear to me whether you are suggesting that CMake should do that. If you do want to suggest that, please file an issue in the tracker. Similarly, CMake does not attempt to analyse the meaning of options specified in add_compile_options(). Again, it's not clear to me whether you are suggesting a new feature for CMake. If you are, please file it in the tracker. No, I don’t suggest CMake should do that, sorry for the confusion. I was just explaining why we need the whole compiler-specific command line, instead of a list of separate flags and include directories - we’ll pass that command line as is (actually with some post-processing) to the compiler to collect the actual defines, header search paths etc. (some examples below) The current proposal (with having separate include_directories, compile_definitions, compile_flags) will force the IDE to assemble the compiler-specific command line itself that is quite prone to errors and will require constant maintenance since additional options may appear (e.g. include_directories may some day have a flag to indicate whether it “” or ) To avoid misunderstandings, please post snippets of CMake code together with a description of what information you want CMake to determine from the snippet and what metadata it should generate. Not sure what you are asking, I hope I made it more clear with previous explanation. * compiler definition do not include compiler-defined(built-in) definitions etc. CMake does not currently gather those during configure, as far as I know. That could be added though. It'd rather not, since the set may be different for the specific files. That is, to have the complete list of include directories and compiler definitions, the IDE will have to call the compiler anyways. And here is where it will need the actual compiler’s command line. Should we had the full list of include directories (split into groups like: , quote, and frameworks) and the list of all compiler defines, we would not need the compiler command-line at all. I think I understand what you're saying. However, it would help if you related what you write to existing CMake features and snippets of CMake code. I assume that you are medium-to-very familiar with CMake features already, given what you are working on? Given the details above, please let me know, if you still need them, I’ll try to collect the specific cases that we support from our test suite. Though I don’t this it’s a way to go for CMake generation, since the compiler should be called for every unique command-line flags and undoubtedly make generation way longer. It's not completely clear to me what you are suggesting here. Maybe you know something I don't know. Can you be clear about what you are suggesting CMake would have to do for each unique command line? I know you are not proposing that CMake should do it (you said the IDE should do it lazily instead), but what action are you actually talking about? What should the IDE do lazily instead of CMake doing it? Invoke the compiler to determine the compiler-defined/built-in include directories and definitions? They will always be the same, right? Or are you talking about the -I- GCC option here and how that clears the built-ins? Please be more specific. We currently reconstruct the command line from the 'build_dir/CMakeFiles/Target1.dir/flags.make’ file
Re: [cmake-developers] Generating buildsystem metadata from CMake
On 01 Apr 2015, at 00:17, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: It comes from CMAKE_CONFIGURATION_TYPES, if project defined such a variable. With default of Debug/Release/RelWithDebInfo/MinSizeRel Ok. So does this mean you have a parser for the existing CMakeCache.txt format already? Yes, at the moment we parse lots of various internal files created by Makefiles generator, and CMakeCache is one of them. Not only do we reed it, we also have the UI that allows user to interact and the cached values. That means we’ll have CMakeCache parser anyways and do not need these values in metadata.json file, as it was mentioned in parallel discussion. Anton Makeev JetBrains http://www.jetbrains.com Develop with pleasure! smime.p7s Description: S/MIME cryptographic 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-developers
[cmake-developers] What commit message will be used when merging topics from stage to next to master
I have a topic that I pushed to stage, so someone else could take a look. At this point, it needed some fixing, so I made some changes to my local topic and pushed those back to the same topic. When I push the topic into next and the testing passes, what checkin string will be used for change list summary purposes? Topic in question: http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/FindCUDA.cmake/CUDA_SOURCE_FILE Thanks, James -- 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] Adding XAML support to Windows Platform
On 04/01/2015 01:33 PM, Gilles Khouzam wrote: patch to add support for XAML files Thanks. Applied and merged to 'next' for testing: VS: Add support for XAML source files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfbc299c I made some minor formatting tweaks, so if you have updates please send patches based on that commit or later. 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] Generating buildsystem metadata from CMake
Anton Makeev wrote: On 01 Apr 2015, at 00:41, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete and cannot be used directly: * include directories list misses compiler-defined search paths CMake gathers those during configure time, and we can add them to the metadata too. However appealing it is, I don’t think it’s a good option, Ok, I understand now, because the used built-in defines are different more often than the built-in include directories (-iquote and -I- are rarely used in my experience, but -std=, -ansi, -fPIC which all cause defines to be added, are common). We’d rather do it lazily when times come to process the given file having specialized caches on IDE side. Ok. Do you currently use compile-commands.json for this? Are you asking for that as an option? That would be an independent feature request. I'd suggest filing it in the tracker. Otherwise, the only way CMake currently would pass such options to the compiler is if the user specified them in CMAKE_CXX_FLAGS or add_compile_options() or similar. Yes, I mean that user may easily have -iquote directly passed as command line option and the IDE need to know that. (e.g. include_directories may some day have a flag to indicate whether it “” or ) Ok, I filed http://public.kitware.com/Bug/view.php?id=15491 Please add any additional information you have, or any design ideas for how the command interface should be. CMake does not attempt to parse CMAKE_CXX_FLAGS for things which look like include directories. That variable is just an opaque string of data from the point of view of CMake. It is not clear to me whether you are suggesting that CMake should do that. If you do want to suggest that, please file an issue in the tracker. Similarly, CMake does not attempt to analyse the meaning of options specified in add_compile_options(). Again, it's not clear to me whether you are suggesting a new feature for CMake. If you are, please file it in the tracker. No, I don’t suggest CMake should do that, sorry for the confusion. I was just explaining why we need the whole compiler-specific command line, instead of a list of separate flags and include directories Ok, thanks. I get it now :). The current proposal (with having separate include_directories, compile_definitions, compile_flags) will force the IDE to assemble the compiler-specific command line itself that is quite prone to errors and will require constant maintenance since additional options may appear (e.g. include_directories may some day have a flag to indicate whether it “” or ) I agree. However, there are two separate use-cases to address. 1) Get information from CMake so that the IDE can understand the C++ 2) Get information to understand the CMake code. You are talking about the first, but I think the second is useful too and an IDE could offer features related only to the CMake code (ie unrelated to the c++ code) based on that information (such as 'Add include directory' action). So, in the end, we probably need tooling to be able to get the information in both forms. Ie, as an array of directories, and as a string of compiler command line options. We already have the latter in the form of compile-commands.json. One of the reasons I wonder if you are using that already is to know whether 1) That is already a good enough solution or 2) The new metadata file should contain similar information I'm wondering if we can learn anything from your experience with the existing file. * compiler definition do not include compiler-defined(built-in) definitions etc. CMake does not currently gather those during configure, as far as I know. That could be added though. It'd rather not, since the set may be different for the specific files. Yes, you're right I think. Given the details above, please let me know, if you still need them, I’ll try to collect the specific cases that we support from our test suite. I think the details you provided above are enough for understanding, but getting some cases from your test suite relating to this stuff would indeed be interesting, I expect. We currently reconstruct the command line from the 'build_dir/CMakeFiles/Target1.dir/flags.make’ file for each target, I see. There are several disadvantages to that, among them being that it ties you to makefiles (until you duplicate your work to support Ninja), and the structure of those files should not be considered 'stable'. CMake should be able to change the way it generates the buildsystem-specific files in any release. We then add additional flags like -dD -M etc. to get the necessary information from the compiler and call (compiler is actually called only once for the unique set of options with cashing etc.). And we have
Re: [cmake-developers] Generating buildsystem metadata from CMake
Tobias Hunger wrote: On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete and cannot be used directly: * include directories list misses compiler-defined search paths CMake gathers those during configure time, and we can add them to the metadata too. That is not necessary for QtC. Feel free to add this information if somebody else needs it. Ok. I have some ideas of how this could be useful, so I'll see about adding it later. snip * compiler definition do not include compiler-defined(built-in) definitions etc. CMake does not currently gather those during configure, as far as I know. That could be added though. That is not necessary for QtC. Feel free to add this information if somebody else needs it. Ok, I think the conclusion is that this is not useful as the built-in defines are very likely to change with different compile flags, which are very likely to be set in the buildsystem *after* CMake would have checked them from the compiler. So, I don't think this will be added. Creator will parse the compile_flags anyway, so it does not matter to me whether some defines/includes end up being hidden in there, but I would prefer to get as much of the information separately if possible. So please keep the include_directories and compile_defines that cmake knows about separate. That is so much nicer to parse than some command line, especially when escaping starts to get necessary. Right. That sounds like an argument for the kind of 'duplication for different use cases/approaches' I just proposed: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12879 That is, to have the complete list of include directories and compiler definitions, the IDE will have to call the compiler anyways. And here is where it will need the actual compiler’s command line. Should we had the full list of include directories (split into groups like: , quote, and frameworks) and the list of all compiler defines, we would not need the compiler command-line at all. We do need to know the compiler *binary* (/usr/bin/gcc), but not necessarily the complete command line that is run (/usr/bin/gcc -c -Dsomething -I/some/path something.cpp something.o). We do of course need to be sure that we have all the information to generate that command line in the form of compile_flags, compile_definitions, include_directories and whichever other flags may be relevant. Ok. If you want to log the compiler-defined defines into the Json file, then cmake obviously needs to query the compiler for those. These defines are heavily dependent on the command line flags you pass (e.g. -std=c++11 will set some other defines than -std=c++98). There is a long list of options that change the defines set by the compiler. Right, this is what I temporarily forgot :). So that means cmake would need to run the compiler once for each possible set of options passed to the compiler during the later build steps, so that it can put this information into the meta-data file. That seems a bit excessive to me, Agreed. even though creator could probably use that information if you did provide it. Currently our projectmanagers just query for the compiler defines themselves. They have to as currently none of the supported build system provides this information. Right, because it's impractical for the buildsystem to provide it, as you wrote. 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
[cmake-developers] [PATCH] Adding XAML support to Windows Platform
I'd like to submit a patch to add support for XAML files to on Windows. This is very similar to the RESX support already on the MSVC generator with the .h and .cpp implementation files being automatically associated with the .xaml file. This would allow WindowsPhone and WindowsStore applications to use the XAML programming model as well as DirectX. I've added a new test VSXaml with produces a WindowsStore 8.1 app (since the rest of the WindowsStore/Phone is already covered in VSWinStorePhone test). By default each Xaml file is treated as a Page, but the type can be specified by setting a new property on the source file (VS_XAML_TYPE). I've validated that all tests run successfully with this change. CMake.Xaml.patch Description: CMake.Xaml.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 0015489]: CMake.ELF test fails when sources are read-only
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15489
==
Reported By:Bill Newcomb
Assigned To:
==
Project:CMake
Issue ID: 15489
Category: CMakeSetup
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-04-01 16:15 EDT
Last Modified: 2015-04-01 16:15 EDT
==
Summary:CMake.ELF test fails when sources are read-only
Description:
When the cmake sources are all set to read-only (e.g. after importing into
perforce), the CMake.ELF test fails because the copy of the binary is also
read-only and cannot be modified.
Steps to Reproduce:
./bootstrap
make
make test
Additional Information:
Assuming one's umask is sane, the following is a patch:
--- /tmp/tmp.10612.25 2015-04-01 13:13:35.0 -0700
+++ /a/cmake-bn/cmake-src/3.2.1/Tests/CMakeTests/ELFTest.cmake.in
2015-04-01 13:12:21.0 -0700
@@ -11,7 +11,7 @@
file(REMOVE_RECURSE ${out})
file(MAKE_DIRECTORY ${out})
foreach(f ${names})
- file(COPY ${in}/${f} DESTINATION ${out})
+ file(COPY ${in}/${f} DESTINATION ${out} NO_SOURCE_PERMISSIONS)
list(APPEND files ${out}/${f})
endforeach()
==
Issue History
Date ModifiedUsername FieldChange
==
2015-04-01 16:15 Bill Newcomb 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
[cmake-developers] [CMake 0015490]: Provide a stable interface to the cmake cache for external tooling
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15490 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15490 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-01 22:25 CEST Last Modified: 2015-04-01 22:25 CEST == Summary:Provide a stable interface to the cmake cache for external tooling Description: External tooling typically parses the CMakeCache.txt file directly in order to extract essential information. The format of the file, and how to parse it are not documented, and it does not have documented stability guarantees. There is a need for tooling to read (and possibly write) cache values, so some stable interface should be provided. That can either mean 1) A new format in a new file 2) Documenting the existing format. The first option has the advantage that a common format for structured documents can be chosen (such as json). The second option has the advantage that external tooling does not need to wait for a new CMake version to generate a new file, because the existing format has not changed in a long time (and maybe can't change because of de-facto stability requirements for existing tools). == Issue History Date ModifiedUsername FieldChange == 2015-04-01 22:25 Stephen Kelly 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] Generating buildsystem metadata from CMake
Anton Makeev wrote: Not only do we reed it, we also have the UI that allows user to interact and the cached values. That means we’ll have CMakeCache parser anyways and do not need these values in metadata.json file, as it was mentioned in parallel discussion. Yes, that's what I thought. I favor documenting the existing format instead of adding a new json format for it. I filed http://public.kitware.com/Bug/view.php?id=15490 to track the idea. 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-developers] Generating buildsystem metadata from CMake
I favor documenting the existing format, too. Note added to issue with my vote. D On Wed, Apr 1, 2015 at 4:26 PM, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: Not only do we reed it, we also have the UI that allows user to interact and the cached values. That means we’ll have CMakeCache parser anyways and do not need these values in metadata.json file, as it was mentioned in parallel discussion. Yes, that's what I thought. I favor documenting the existing format instead of adding a new json format for it. I filed http://public.kitware.com/Bug/view.php?id=15490 to track the idea. 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 -- 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
