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

[David Cole]

"5." is more work, but a good idea...

And since your recent activity on the mailing list rivals my own,
you'd never hear me calling you "an outsider". ;-)

I tend to think things like this (problems without an obvious, easy,
code-it-right-up solution...) should be slept on for a few
nights/weeks before action. Especially since there's an easy way to
write a CMake language wrapper function for now. If it still seems
like a good idea after some sleep, then we can tackle figuring out the
exact details. But, hey, ... if it seems obvious and easy to somebody
else here, then by all means, send the patch along for review. :-)


Thx,
D



On Thu, Apr 23, 2015 at 7:21 AM, Petr Kmoch <petr.kmoch at gmail.com> wrote:
> I hope you don't mind an outsider chipping in with a potential 5th
> possibility:
>
> 5. parse the file to be configured to discover which variables will be
> necessary for the configuration, and save only *their* values. For any but
> the most insane configure_file() calls, that should be a tiny subset of all
> the variables in existence, and should hopefully keep the memory
> requirements at a manageable level. The value could even be shared by
> different configure_file() calls if they're the same.
>
> Petr
>
> On Thu, Apr 23, 2015 at 1:00 PM, David Cole via CMake <cmake at cmake.org>
> wrote:
>>
>> 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
>> --
>>
>> 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
>
>