Re: CMake compiler flags handling

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Thu, 10 Jun 2021 01:22:45 +0200
schrieb "Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>: 

> -set(CMAKE_C_FLAGS_INIT "$ENV{CFLAGS} ${CMAKE_C_FLAGS_INIT}")
> +set(CMAKE_C_FLAGS_INIT "${CMAKE_C_FLAGS_INIT} $ENV{CFLAGS}")

Meh. That doesn't actually do anything sensible. Stupid. At that point,
${CMAKE_C_FLAGS_INIT} is an empty string anyway (only sometimes?).
Sorry. It seemed so simple for a moment, but totally the wrong tree
being barked up.

It's more involved to change the established cult of CMake from always
appending after environment flags got inserted. Avoiding hardcoded
optimization level flags might be the next best thing. Funny enough,
LAPACK does this:

if( "${CMAKE_Fortran_FLAGS_RELEASE}" MATCHES "O[3-9]" )
  message( STATUS "Reducing RELEASE optimization level to O2" )
  string( REGEX REPLACE "O[3-9]" "O2" CMAKE_Fortran_FLAGS_RELEASE
          "${CMAKE_Fortran_FLAGS_RELEASE}" )
  set( CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE}"
       CACHE STRING "Flags used by the compiler during release builds" FORCE )
endif()

After all … pkgsrc could also define a differing default
CMAKE_BUILD_TYPE, creating a new one, even.

So my post is mostly about this part:

> But it's awfully specific to only this toolchain. I wonder … should we
> extend that to others hat might possibly be relevant? GNU-Fortran comes
> to mind, which does
> 
> # No -DNDEBUG for Fortran.
> string(APPEND CMAKE_Fortran_FLAGS_MINSIZEREL_INIT " -Os")
> string(APPEND CMAKE_Fortran_FLAGS_RELEASE_INIT " -O3")
> 
> and Intel and PGI on top … the former I have used in the past to build
> a small pkgsrc tree.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg