On Thu, May 21, 2015 at 09:31:41 -0400, Taylor Braun-Jones wrote:
> So I added another workound for that:
>
> if(${CMAKE_GENERATOR} MATCHES ".* Makefiles$")
> set(environment_build_flags "$ENV{MAKEFLAGS}")
> endif()
>
> add_custom_target(coverage_data
> COMMAND env --unset=MAKEFLAGS ${bullseye_environment}
> ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR} --clean-first --
> ${environment_build_flags}
> COMMAND env ${bullseye_environment} ${CMAKE_CTEST_COMMAND}
> --output-on-failure
> COMMENT "Generating test coverage data"
> VERBATIM
> )
>
> Which allows the parallelism to work properly in an environment like:
>
> export MAKEFLAGS=$(grep -i -c ^processor /proc/cpuinfo)
> make coverage_data
The problem with MAKEFLAGS is that `-i` also gets inherited and that is
not acceptable to use when running things like try_compile since it
causes false positives (e.g., detecting NEON extensions on x86). CMake
clears it so that it has a better expectation of how things will run. Is
there a reason you can't use a CMake cache variable to set
`environment_build_flags` rather than the environment (since it would
get remembered between cmake runs while the environment needs to be
specified every time)?
--Ben
--
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-developers
