[MacPorts] #49108: CMake Portgroup: use a custom CMAKE_BUILD_TYPE
#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 Keywords: haspatch | Port: -------------------------+-------------------------------- I cannot speak for earlier versions, but since v2.8.x cmake has been (increasingly?) strict about the compiler and linker flags used with the 4 builtin build types (Release, RelWithDebInfo etc). There is undoubtedly a good reason for that, but it does seem to clash with MacPorts' own conventions because it makes it about impossible to control exactly what options are used. Debian and Ubuntu circumvent this by using `-DCMAKE_BUILD_TYPE=Debian`. There is no patch (to my knowledge) that adds this preset to cmake; it simply causes cmake to use `CMAKE_CXX_FLAGS` and family instead of `CMAKE_CXX_FLAGS_RELEASE` (or `*_RELWITHDEBINFO` etc). In addition, flags passed through the `CXXFLAGS` etc. env. variables end up in `CMAKE_CXX_FLAGS` and family. I propose to follow the same approach in MacPorts, so that the usual mechanisms for setting compiler and linker options work completely as expected. -- Ticket URL: <https://trac.macports.org/ticket/49108> MacPorts <https://www.macports.org/> Ports system for OS X
#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 ryandesign@…): Thanks. Can you give a specific example of a problem that is caused by not applying this patch? -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#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
#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@…): Somehow I missed the fact that the CMake portgroup does an explicit definition of `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS`. That cancels the intended effect. Remove those definitions, and my change has the intended effect. I'm preparing a new diff, but want to take some feedback into account. Question: is there a hard reason to use -DNDEBUG? One could include `${configure.c*flags}` in that explicit definition, but that means the definition gets set at the moment the portgroup is included, and can no longer take any tweaking of `CFLAGS`, `CXXFLAGS` (etc?) into account that might occur after that moment (which is typically at the head of a Portfile). Concerning a few comments in the PortGroup file: Re: the ObjC equivalents: consensus of the CMake developers appears to be that there is no need for CMAKE_OBJC*_FLAGS (and they know best after all, don't they ...). Re: CPPFLAGS: no development on the cited ticket. There is the possiblity to use `-DINCLUDE_DIRECTORIES=?` but that would mean filtering out any preprocessor options that aren't `-I` options. Maybe one should write a `pre-configure` block in the CMake PortGroup that takes the final value of ${CPPFLAGS}, collects the -I options to initialise `INCLUDE_DIRECTORIES`, and adds the remaining options to at least CFLAGS and CXXFLAGS in `configure.env`? It would make life easier if CMake allowed things like `-DINCLUDE_DIRECTORIES+=foo` but that appears not to be the case. One can only set variables, not append to them (like in CMake files, though there at least one can use a variable's current value, which also seems impossible on the commandline). -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#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@…): Modified attachment diff: I've change the `pre-configure` block according to my comments above. Seems to work as intended now; both pure CMake ports and KDE4 ports build with the flags configured either by default or through commandline use of `configure.optflags`. -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#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@…): BTW, it could be very useful if "base" stored the complete configure command line in a separate file (in the work directory, like the .CC_PRINT_OPTIONS file) rather than only in the main.log . -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#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@…): Alternatively, one can do lots of overriding and initialisation stuff via a `-C <initial-cache> = Pre-load a script to populate the cache.` command line argument. That would require writing the variables to set to a file in `port work`, using the "full" CMake syntax. Not impossible, but more cumbersome. -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
#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@…): It was about time I updated this patch to match the current CMake PortGroup file. As a result, it contains other enhancements also submitted elsewhere: - add a mechanism to facilitate modifying the rpath from a Portfile. This is for ports depending on libraries outside of ${prefix}/lib that do not contain the full path to their install location (which may be more common on platforms other than Darwin/OS X). - always generate a ${build.dir}/compile_commands.json file (port developer feature) - store the details of the cmake invocation in ${workpath}/.macports.${subport}.configure.cmd (port developer feature) -- Ticket URL: <https://trac.macports.org/ticket/49108#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts