Maybe not the most elegant, but here's one way. You could initiate a trivial dummy sub-build. By this I mean execute a separate CMake run for a dummy project off to the side somewhere and have it generate a file with the results of the queries you want, then include() that generated file in your main build. The sub-build doesn't have to actually build anything, just run CMake. In your main build, you can then use that knowledge to set AFL_PATH, etc. at the point you wanted to above. Loosely, just so you can get an idea, it would go something like this (untested):
*Top level CMakeLists.txt*: option(ENABLE_FUZZ "Use AFL fuzz wrapper" OFF) if(ENABLE_FUZZ) execute_process(COMMAND ${CMAKE_COMMAND} -E mkdir ${CMAKE_CURRENT_BINARY_DIR}/afl_test) execute_process(COMMAND ${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}/afl_test WORKING_DIR ${CMAKE_CURRENT_BINARY_DIR}/afl_test) include(${CMAKE_CURRENT_BINARY_DIR}/afl_test/afl_setup.cmake) endif() project(MyProj) *afl_test/CMakeLists.txt:* project(AFL_TEST) file(WRITE afl_setup.cmake "set(AFL_PATH /* depends on CMAKE_C_COMPILER_ID */) set(ENV{AFL_CC} ${CMAKE_C_COMPILER}) set(CMAKE_C_COMPILER ${AFL_PATH})") Hopefully that gives you enough of an idea to be able to give this approach a try. On Tue, May 24, 2016 at 2:32 AM, Andrew Melo <andrew.m...@gmail.com> wrote: > Hi all, > > I'm wanting to enable a couple of different options to enable/disable > compiler wrappers in my project. I would like to do something roughly > like this (and something similar to make ccache work right) > > option(ENABLE_FUZZ "Use AFL fuzz wrapper" OFF) > if(ENABLE_FUZZ) > set(AFL_PATH /*depends on CMAKE_C_COMPILER_ID*/) > set(ENV{AFL_CC} ${CMAKE_C_COMPILER}) > set(CMAKE_C_COMPILER ${AFL_PATH}) > endif() > > ..but I hit a chicken and the egg problem. If I place project() above > this, cmake gets mad that I changed the compiler with "You have > changed variables that require your cache to be deleted....", and > messes up all of the set variables. If I place project() below this, > CMAKE_C_COMPILER_ID is unset, which means I can't choose the right > wrapper for AFL_PATH. Finally, if I do none of the above, and force > everyone to do "cmake -DCMAKE_C_COMPILER=<afl wrapper path> ..", the > user has to remember to always manually set the AFL_CC environment > variable each time they build, or the wrong underlying compiler is > chosen > > What's the best move here? Is there some other "magic" variable I can > set to change the actual executable cmake calls, while not triggering > a cache rebuild? Is there a robust way to get the "presumptive" > compiler ID before project() is called? > > Thanks! > Andrew > > > > -- > -- > Andrew Melo > -- > > 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 > -- Craig Scott Melbourne, Australia http://crascit.com
-- 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