[MacPorts] #49108: CMake Portgroup: use a custom CMAKE_BUILD_TYPE

MacPorts noreply at macports.org
Tue Oct 6 03:44:42 PDT 2015


#49108: CMake Portgroup: use a custom CMAKE_BUILD_TYPE
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.3.4
Resolution:               |   Keywords:  haspatch
      Port:               |
--------------------------+--------------------------------

Comment (by rjvbertin@…):

 Not really an example of an actual problem, no. Unless it's considered a
 problem that without this patch MacPorts isn't in complete control of the
 compiler (and linker) options used in cmake builds.

 Building with CMAKE_BUILD_TYPE=Release will set the compiler flags to a
 set decided upon by CMake. Options passed through configure.optflags (as
 well as those set by base) are not (always) completely ignored but they
 are not the only options passed on. That is not to claim that the options
 used currently in standard cmake builds are wildly different from what
 MacPorts wants them to be...

 I have to admit that I have never really understood how those preset flags
 interact with attempts to set them via CFLAGS, CXXFLAGS etc. and that is
 partly because KDE4's cmake files override cmake's presets. I do know that
 when building KDE4 applications, user-specified options from CXXFLAGS are
 PREpended to the preset options, which means for instance that `-O2`
 specified by the user will be overridden by the preset `-O3` for the
 Release build type (or -O3 overridden by -O2, you get the drift).

 It is of course possible to override the presets on the command line (at
 least I think so), but you'd have to set all CMAKE_*FLAGS_* variables.

 Just using a custom CMAKE_BUILD_TYPE is more straightforward and
 predictable, which is undoubtedly why Debian and Ubuntu follow that
 approach in their packaging scripts.

 In other words, this patch is more like the recent-ish patch to
 port:automoc that moved its cmake files to the place where MacPorts stores
 such files.

 I could try to hunt down the feedback given on one my ports a while back
 that told me to pass on ${configure.optflags} to a non-standard build
 system via configure.*flags. That feedback (I think it was from you even)
 is ultimately what inspired this patch.

-- 
Ticket URL: <https://trac.macports.org/ticket/49108#comment:2>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list