I can only imagine that would cause IMMENSE problems. I depend on configure_file being an immediate action in many many many places. (i.e. -- the very next line of code in my CMakeLists.txt file can depend on the result of configure_file being on disk and up to date at the moment of configure processing...)
Now, having said that, I could imagine you may want to change *some* configure_file calls to file(GENERATE calls. Or to enable @@ substitution in something like an explicit configure_file(GENERATE signature. I would not think it wise or advisable to defer existing configure_file calls to generate time. Not by a long shot... David C. On Tue, Apr 21, 2015 at 3:26 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-04-18 11:35+0200 Stephen Kelly wrote: > >> Alan W. Irwin wrote: >> >>> So is it recommended that a two-step procedure be used to configure >>> a file? For example: >> >> >> Yes, that seems to be a valid thing to do. >> >>> If the above complications for configured files are the only way to >>> deal with a mixture of @...@ items and generator expressions to >>> configure, could a change to configure_file so that it honors >>> generator expressions be implemented to avoid these complications? >> >> >> Nope, generator expressions are only available at generate-time, but >> configure_file is evaluated before that. > > > I was well aware of that so I assumed if this was implemented > configure_file would be moved to generate-time as well. > > So there are really two questions here. (1) Could the move to > honoring generator expressions by configure_file (as well as moving > configure_file to generate time) be straightforwardly implemented, and > (2) would that move cause any problems for users (because of > the necessary move to generate-time). > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > -- > > 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