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

Petr Kmoch petr.kmoch at gmail.com
Thu Apr 23 07:21:40 EDT 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150423/52509eb4/attachment.html>


More information about the CMake mailing list