[cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Alan W. Irwin]

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.

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
__________________________