[CMake] Chicken/egg w/CMAKE_C_COMPILER

[Craig Scott]

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.melo at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160524/c9b31ab1/attachment.html>