[cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Konstantin Podsvirov]

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