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
