Michael Wild <them...@gmail.com> writes: > The problem is, CMake has to go through the system shell. Of course, > CMake could write the command to a file and then invoke a custom > interpreter from the system shell, but that would probably be very > inefficient and would require CMake to implement a full shell > language.
Another option for cmake is to appropriately quote the string so the system shell does not alter it. Consider cmake -E echo "#hello" cmake would put on the Unix makefile something like cmake -E echo "\#hello" and on windows MinGW makefile or VS project it would be cmake -E echo "#hello" [snip] > But we still don't know what your general goal is, WHY you need this > and why e.g. a simple add_definitions() isn't enough (because so far I > haven't seen anything that requires you to do this stuff dynamically > at build-time). This is not the issue. As mentioned on the previous posts, the question is how much confidence can I have on the platform independence of the -E commands. The stated goal is to provide platform isolation. We have seen that this is not completely true. But if you insist on knowing the context that raised the issue, it consisted on the requirement of creating a header file containing a #define with a quoted list of the names of the source files of the project. configure_file is a solution, but requires having a pre-existing .in file and I'll like to avoid polluting the source tree as much as possible. Then add_custom_command seemed a good fit. Maintenance-wise, it is simpler than configure_file+file.in or file(WRITE+configure_file and has the added feature of regenerating the file if it is deleted by mistake. So here we are. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
