Re: [cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
On Mon, Apr 24, 2017 at 3:03 PM, Brad King wrote: > On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote: > > Where execute_process INPUT_CONTENT or INPUT_VARIABLE? > > > > This would be very convenient for a small input. > > > > Why should I always write a file for input? > > I agree that the options should be there but they can't be easily > implemented without choosing our own temporary file which will have > its own problems. > > The reason is that our internal process execution implementation > does not support communication from the parent on stdin. Fixing > that is not something I'm prepared to do or even accept as a > contribution because I'd rather migrate to libuv than extend our > own process management implementation further. Brad, can you share what the current status is on this? If I remember correctly, then libuv cannot be built yet on all necessary compilers. Is that still the case? This sounds like the biggest impediment. Once we can rely on libuv, we can also use it for filesystem operations. This would help solve issues like #13162. Cheers, Daniel -- 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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
Hi!16:05, 24 April 2017 г., Brad King :On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote: Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input?I agree that the options should be there but they can't be easilyimplemented without choosing our own temporary file which will haveits own problems.The reason is that our internal process execution implementationdoes not support communication from the parent on stdin. Fixingthat is not something I'm prepared to do or even accept as acontribution because I'd rather migrate to libuv than extend ourown process management implementation further. That is a morelong-term process so in the meantime I think it is best to justask projects to use INPUT_FILE.-BradI apologize. I saw the library libuv in the dependencies and thought that it was used in the current implementation.I incorrectly assumed that this function is easy to add.__RegardsKonstantin Podsvirov -- 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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote: > Where execute_process INPUT_CONTENT or INPUT_VARIABLE? > > This would be very convenient for a small input. > > Why should I always write a file for input? I agree that the options should be there but they can't be easily implemented without choosing our own temporary file which will have its own problems. The reason is that our internal process execution implementation does not support communication from the parent on stdin. Fixing that is not something I'm prepared to do or even accept as a contribution because I'd rather migrate to libuv than extend our own process management implementation further. That is a more long-term process so in the meantime I think it is best to just ask projects to use INPUT_FILE. -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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
23.04.2017, 12:26, "Alan W. Irwin" : > On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote: > >> Hi Alan! >> >> 23.04.2017, 10:01, "Alan W. Irwin" : >>> On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote: >>> Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input? >>> >>> Hi Konstantin: >>> >>> I assume that last sentence refers to using the CMake FILE command >>> directly to write the required file at cmake time in the build tree >>> (as opposed to having to create an actual permanent file in the source >>> tree to be used directly or as a prototype for a configured file in >>> the build tree)? If so, I use that approach quite a bit in various >>> build systems I have helped to develop to help drastically reduce the >>> number of small CMake-related files in the source tree. And I far >>> prefer that approach to what you seem to be asking for above which is >>> some added syntax variation to EXECUTE_PROCESS to provide the same >>> ability that the FILE command currently has. >>> >>> Note, I had to make some assumptions when answering you, and my >>> apologies in advance if I have misinterpreted anything you said >>> above. >> >> You have correctly understood and assumed. Thanks for your reply. > >> But imagine that we need to perform a simple process and process its > > standard output. But this process unfortunately awaits user input to > complete. > > Interesting use case! > > Of course, if it is really simple user input to the process involving > just a few values, then for that use case the user could enter those > values via environment variables or CMake variables while the designed > build system writes those via FILE to a temporary file in the right > order that is then read by the process that is being executed by > execute_process. But that idea becomes clumsy as the number of values > increases. So I agree it would be useful to deal with the case where > user input of a substantial number of values via stdin (presumably > interactively prompted by the process to help guide that user input) > is the best and most flexible way to control the process. No. Do not complicate things. You do not need to implement interactive communication with the user through CMake streams. I just want to add the convenient INPUT_CONTENT and INPUT_VARIABLE options. The input data is known in advance, even before the process is started. > One possibility to address that use case is whenever an appropriate > optional argument was specified to execute_process, i.e., that > execute_process command had the correct optional signature, then, for > example, you could connect cmake stdin with the stdin for the process > that is being executed by execute_process. > > Of course, one concern with this solution for the use case might be > this makes the user build process difficult for a project's developers > to debug in case the whole thing is failing because the user typed in > the wrong stdin data for the process. But I would argue against that > concern because this capability does give CMake-based build-system > designers more power and freedom which I fundamentally like as such a > build-system designer. And with each such additional increase in power > and freedom of CMake, build-system designers have a documentation > responsibility (i.e., in this case documenting exactly the stdin user > choices for the process they have forced users to run at cmake time > with execute_process), and the process design responsibility > (sanitizing user input, prompting user input, etc.). Also > build-system users have the responsibility of reading that process > input documentation! :-) > > I must stop there because I have test project simplification and very > likely git bisect work to do on a completely different issue I have > raised here today. > > Alan > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __ > > Linux-powered Science > __ -- Regards, Konstantin Podsvirov -- 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 Cou
Re: [cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote: Hi Alan! 23.04.2017, 10:01, "Alan W. Irwin" : On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote: Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input? Hi Konstantin: I assume that last sentence refers to using the CMake FILE command directly to write the required file at cmake time in the build tree (as opposed to having to create an actual permanent file in the source tree to be used directly or as a prototype for a configured file in the build tree)? If so, I use that approach quite a bit in various build systems I have helped to develop to help drastically reduce the number of small CMake-related files in the source tree. And I far prefer that approach to what you seem to be asking for above which is some added syntax variation to EXECUTE_PROCESS to provide the same ability that the FILE command currently has. Note, I had to make some assumptions when answering you, and my apologies in advance if I have misinterpreted anything you said above. You have correctly understood and assumed. Thanks for your reply. But imagine that we need to perform a simple process and process its standard output. But this process unfortunately awaits user input to complete. Interesting use case! Of course, if it is really simple user input to the process involving just a few values, then for that use case the user could enter those values via environment variables or CMake variables while the designed build system writes those via FILE to a temporary file in the right order that is then read by the process that is being executed by execute_process. But that idea becomes clumsy as the number of values increases. So I agree it would be useful to deal with the case where user input of a substantial number of values via stdin (presumably interactively prompted by the process to help guide that user input) is the best and most flexible way to control the process. One possibility to address that use case is whenever an appropriate optional argument was specified to execute_process, i.e., that execute_process command had the correct optional signature, then, for example, you could connect cmake stdin with the stdin for the process that is being executed by execute_process. Of course, one concern with this solution for the use case might be this makes the user build process difficult for a project's developers to debug in case the whole thing is failing because the user typed in the wrong stdin data for the process. But I would argue against that concern because this capability does give CMake-based build-system designers more power and freedom which I fundamentally like as such a build-system designer. And with each such additional increase in power and freedom of CMake, build-system designers have a documentation responsibility (i.e., in this case documenting exactly the stdin user choices for the process they have forced users to run at cmake time with execute_process), and the process design responsibility (sanitizing user input, prompting user input, etc.). Also build-system users have the responsibility of reading that process input documentation! :-) I must stop there because I have test project simplification and very likely git bisect work to do on a completely different issue I have raised here today. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
Hi Alan! 23.04.2017, 10:01, "Alan W. Irwin" : > On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote: > >> Where execute_process INPUT_CONTENT or INPUT_VARIABLE? >> >> This would be very convenient for a small input. >> >> Why should I always write a file for input? > > Hi Konstantin: > > I assume that last sentence refers to using the CMake FILE command > directly to write the required file at cmake time in the build tree > (as opposed to having to create an actual permanent file in the source > tree to be used directly or as a prototype for a configured file in > the build tree)? If so, I use that approach quite a bit in various > build systems I have helped to develop to help drastically reduce the > number of small CMake-related files in the source tree. And I far > prefer that approach to what you seem to be asking for above which is > some added syntax variation to EXECUTE_PROCESS to provide the same > ability that the FILE command currently has. > > Note, I had to make some assumptions when answering you, and my > apologies in advance if I have misinterpreted anything you said > above. You have correctly understood and assumed. Thanks for your reply. But imagine that we need to perform a simple process and process its standard output. But this process unfortunately awaits user input to complete. > > Alan > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __ > > Linux-powered Science > __ My suggestion: Add support for the INPUT_CONTENT or INPUT_VARIABLE arguments in execute_process command. It seems to me that this will be a very useful improvement. Will anyone take up the implementation of this improvement? -- Regards, Konstantin Podsvirov -- 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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote: Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input? Hi Konstantin: I assume that last sentence refers to using the CMake FILE command directly to write the required file at cmake time in the build tree (as opposed to having to create an actual permanent file in the source tree to be used directly or as a prototype for a configured file in the build tree)? If so, I use that approach quite a bit in various build systems I have helped to develop to help drastically reduce the number of small CMake-related files in the source tree. And I far prefer that approach to what you seem to be asking for above which is some added syntax variation to EXECUTE_PROCESS to provide the same ability that the FILE command currently has. Note, I had to make some assumptions when answering you, and my apologies in advance if I have misinterpreted anything you said above. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input? -- Regards, Konstantin Podsvirov -- 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