[Zeek-Dev] CFLAGS/CXXFLAGS bug with configure

[Jim Mellander]

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 at corelight.com> wrote:

> On Wed, May 29, 2019 at 10:30 AM Jim Mellander <jmellander at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190530/1a603ad5/attachment.html