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@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 <nilsglad...@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 >
-- 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
