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 .
