[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