Thanks, sounds like a CMake bug, or at least a violation of the Principle of Least Surprise - explicit settings are always expected to override defaults....  In any event, in the Zeek context, this thread should suffice to document this (admittedly obscure) issue, and mitigation.



On Wed, May 29, 2019 at 2:21 PM Jon Siwek <jsiwek@corelight.com> wrote:
On Wed, May 29, 2019 at 10:30 AM Jim Mellander <jmellander@lbl.gov> wrote:

> There appear to be several alternatives to allow supplied flags to override the defaults, the most reasonable appearing to be modifying the build commands to apply CFLAGS/CXXFLAGS after the defaults.
>
> I'm not a cmake maven, but it seems likely that lines like:
> set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS}   ${bro_cache_CMAKE_C_FLAGS}")
>
> could be reversed ala:
>
> set(CMAKE_C_FLAGS   "${bro_cache_CMAKE_C_FLAGS}   ${CMAKE_C_FLAGS}")
>
> to achieve that effect.

The couple places where we set CMAKE_C{XX}_FLAGS don't seem to matter:
the flags associated with CMAKE_BUILD_TYPE always come last in the
generated Makefile and I think that's just what CMake does, not
something we can control.

However, you should be able to bypass CMake from inserting build-type
flags entirely if you supply an unknown/bogus build type:

    CFLAGS='-O3' CXXFLAGS='-O3' ./configure --build-type=none

- Jon