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

[David Cole]

There's also a fourth possibility:

4. Delay the configure processing for these "configure and generate"
files with the final variable values at the END of the configure (*at*
generate time).

Then there are no memory or temp file issues, but you have a mismatch
with the existing (and reasonably expected) behavior of configure_file
which does immediate processing.

That would be inconvenient, if not impossible, for folks to use
predictably from the scope of sub-directories.

Seems we have not stumbled upon the win-win idea yet...


D


On Thu, Apr 23, 2015 at 6:44 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> On 04/23/2015 12:13 PM, Alan W. Irwin wrote:
>>
>> I think your idea of configure_file(GENERATE...) (where configure_file
>> occurs at configure-time without GENERATE to be backwards compatible,
>> but it occurs at generate-time if the new GENERATE signature is used)
>> is an excellent way to allow users to replace the current clumsiness
>> that is required to configure a file with both @ symbols and
>> generator expressions.
>
>
> I suppose for that to work configure_file() would have to either:
>
> 1. Store the values of all variables as they were set during the
> configure_file() call so that they can be expanded during generation.
>
> 2. Or perform variable substitution in-memory during the call and store the
> intermediate content for generator expressions substitution at generation
> time.
>
> 3. Or perform variable substitution during the call and store the
> intermediate content in a temporary file which then gets generator
> expression substitution at generation time.
>
> None of those sound really optimal.
>
> With 1. and 2. memory requirements might get out of hand.
>
> With 3. you are basically back to something that acts like a
> configure_file() + file(GENERATE) wrapper except that cmake now has to come
> up with temporary filenames.
>
> Nils