Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ?? In the meantime, while it is certainly clumsy to do the two separate commands everywhere, you could write a CMake language function(configure_file_generate ...) that takes the same args as configure_file, but does the two step in its implementation.
Then, at least, your clumsiness is reduced, and you can simply replace configure_file with configure_file_generate everywhere it is necessary. I would volunteer to take this on, but I'd be promising my time falsely. Perhaps another season... Cheers, David C. On Thu, Apr 23, 2015 at 6:13 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-04-21 15:54-0400 David Cole wrote: > >> I can only imagine that would cause IMMENSE problems. > > > Good point about keeping backwards compatibility, but your shift key > got stuck. :-) > >> >> 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 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. > > And to repeat how bad that clumsiness is, two separate commands > currently have to be used to do the job, and the syntax for those > commands is very different from each other with one having input file > first than output file and the other having those reversed with > special labels for each! So having the possibility of replacing all > that clumsiness with configure_file(GENERATE...) would be really nice. > > And no I don't have the C++ skills or knowledge of the internal > workings of CMake to create a patch to implement that, but I hope a > CMake developer is inspired to do that by this discussion. > > > 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
