[CMake] cmp0026, file(GENERATE...), and configure_file

[David Cole]

I can only imagine that would cause IMMENSE problems.

I depend on configure_file being an immediate action in many many many
places. (i.e. -- the very next line of code in my CMakeLists.txt file
can depend on the result of configure_file being on disk and up to
date at the moment of configure processing...)

Now, having said that, I could imagine you may want to change *some*
configure_file calls to file(GENERATE calls. Or to enable @@
substitution in something like an explicit configure_file(GENERATE
signature.

I would not think it wise or advisable to defer existing
configure_file calls to generate time. Not by a long shot...


David C.


On Tue, Apr 21, 2015 at 3:26 PM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2015-04-18 11:35+0200 Stephen Kelly wrote:
>
>> Alan W. Irwin wrote:
>>
>>> So is it recommended that a two-step procedure be used to configure
>>> a file?  For example:
>>
>>
>> Yes, that seems to be a valid thing to do.
>>
>>> If the above complications for configured files are the only way to
>>> deal with a mixture of @...@ items and generator expressions to
>>> configure, could a change to configure_file so that it honors
>>> generator expressions be implemented to avoid these complications?
>>
>>
>> Nope, generator expressions are only available at generate-time, but
>> configure_file is evaluated before that.
>
>
> I was well aware of that so I assumed if this was implemented
> configure_file would be moved to generate-time as well.
>
> So there are really two questions here.  (1) Could the move to
> honoring generator expressions by configure_file (as well as moving
> configure_file to generate time) be straightforwardly implemented, and
> (2) would that move cause any problems for users (because of
> the necessary move to generate-time).
>
> 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