Re: why does devel/cmake's Makefile subst's out compiler optimization?

[Chuck Cranor <chuck%ece.cmu.edu@localhost>]

On Thu, Apr 05, 2018 at 07:56:32AM +0200, Thomas Klausner wrote:
> On Wed, Apr 04, 2018 at 09:22:12PM -0400, Chuck Cranor wrote:
> >      unfortunately, a cmake compiled with pkgsrc breaks this (note
> > that all "-O"'s are filtered out):
> 
> In pkgsrc, we generally patch packages to honor the users CFLAGS,
> including the ones for -O. Here cmake would override them, which goes
> against this idea.


The problem with this is that you are changing the semantics
of the CMAKE_BUILD_TYPE variable to be incompatable with normal
cmake installs.   

Users that are familiar with cmake and are using it to compile
their own cmake-based projects outside of pkgsrc expect that 
"-DCMAKE_BUILD_TYPE=Release" is going to turn on the optimizer.
With this change:

   1. this is no longer true

   2. the user is not likely to even notice their project isn't getting
      optimized as cmake doesn't print the compile commands (unless 
      you do something like "make VERBOSE=1" to build).


Since pkgsrc/mk/configure/cmake.mk doesn't set a CMAKE_BUILD_TYPE
for projects that pkgsrc builds, having optimizer flags in variables
like ${CMAKE_C_FLAGS_RELEASE} should not impact pkgsrc builds.
so you'd think there would be no need to subst.mk them out...

However, there are some cmake-based packages that set a non-null
default build type if one isn't give... e.g. they do something
like this:

        if (NOT CMAKE_BUILD_TYPE)
            set (CMAKE_BUILD_TYPE Release
                 CACHE STRING "Choose the type of build." FORCE)
        endif ()

in that case you might have to have pkgsrc/mk/configure/cmake.mk
set CMAKE_BUILD_TYPE to some non-null dummy value to avoid the 
above defaulting behavior...


chuck