23.04.2017, 12:26, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>: > On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote: > >> Hi Alan! >> >> 23.04.2017, 10:01, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>: >>> 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 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