[macports-ports] 01/04: aften: An A/52 audio encoder

Michael Dickens michaelld at macports.org
Fri Apr 6 12:34:57 UTC 2018


The issue being that if a port's configure checks for the build type (e.g., {{{
if(${CMAKE_BUILD_TYPE} STREQUAL "Release") then
...
elseif
}}}
and so forth, and if "MacPorts" is not in BUILD_TYPEs list -- no matter whether it has settings available for use by CMake already --, then cmake errors out. See, e.g., < https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GrBuildTypes.cmake >. Yes, I know I can always add "MacPorts" to the list and/or tweak the CMAKE_BUILD_TYPE in the portfile to be something acceptable. Again: That takes (a little) work and testing /debugging to make sure it's correct. It also removes some of the point of updating to cmake 1.1 PG: to simplify Portfiles and add MP-specific options for building. Although the cmake 1.0 PG works out of the for my ports (per design), I will update those ports that don't check for the BUILD_TYPE to the 1.1 PG as I find time. I'm not sure what I'll do with my ports that do check the BUILD_TYPE. - MLD

On Fri, Apr 6, 2018, at 8:21 AM, Ryan Schmidt wrote:
> The fact that the cmake 1.1 portgroup uses build type "MacPorts", not 
> "Release", is meant to be a feature, not a bug:
> 
> https://trac.macports.org/ticket/52699#comment:1
> 
> > • use CMAKE_BUILD_TYPE=MacPorts. Inspired by Debian's own build type, this allows us to specify all compiler settings via the well-known configure.* commands and exported via the environment. If one of CMake's predefined types is used the corresponding standard options will be *appended* to our options, which will override notably the optimisation options. Some parsing of configure.cppflags, configure.cflags and configure.cxxflags is done to ensure this works as expected, in lines 145-200 .


More information about the macports-dev mailing list