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 .

Reply via email to