Errors when changing cmake build directory

Michael Dickens michaelld at
Thu May 2 20:12:52 UTC 2019

Hi Fred - My thoughts follow. This will likely be my only reply to your post or reply here since it's heading toward being off-topic & honestly comes down much more to personal preference than any technical requirement; it's more along the lines of a "culture war" such as "Mac versus PC", "iPhone versus Android" and the like. Each side has benefits and drawbacks; neither side is entirely in the right nor in the wrong. There is very little point in flaming such wars.

(1) CMake and in-source versus out-of-source:

In my opinion you're not correct: CMake itself is build-location agnostic; it does not default to in-source builds. Individual projects may choose to provide just in-source building, but in my experience the vast majority of projects that use CMake for building can be built in-source or out-of-source. 

When one issues the "cmake" command, the final argument is the directory containing the top-level CMakeLists.txt file in the source to be built; this directory can be relative (e.g., ".", or ".."), or absolute (e.g., "/path/to/top/level/cmakelist_txt/dir/"). Modern and recent CMake itself is agnostic as to whether one builds in-source or out-of-source; such CMake has no default either way, whether explicit or implicit. NOTE: I do think that -very old- CMake maybe did require in-source builds, but we're talking version 1 or maybe early version 2 -- many years ago!

In my many years of using CMake (since sometime in mid-version 2), CMake has worked for both in-source and out-of-source builds quite robustly; the CMake scripting required to make it work both ways is nominally different than requiring in-source builds. Some projects wrote their original CMake scripts with in-source in mind, and have never bothered to update their CMake scripts to allow for out-of-source builds. The vast majority of projects that I've ever heard of or experienced that use CMake work with out-of-source builds, whether because the CMake scripts were originally written in the generic build location style, or because they were fixed to allow building either way.

(2) cmake PG settings:

The default cmake 1.1 PG settings are for out-of-source builds: yes! But, one can in any individual Portfile change this setting quite easily or just use the cmake 1.0 PG, which defaults to in-source builds (with the option of doing out-of-source builds if set specifically in the Portfile using this PG). v1.1 is more robust overall, but v1.0 is probably plenty sufficient for many ports.

(3) benefit of cmake out-of-source builds:

The benefit of out-of-source builds is negligible in the MP environment: true if you're just an end-user! I tend to believe that most MP users just want MP to work, whether compiling from source or installing via a pre-built archive. CMake out-of-source builds are meaningless from this perspective.

That said, to get ports to the point where they install and work robustly, the out-of-source build is a convenience for developers who are doing the work to get ports to this point. I have scripts that allow me to manipulate project source code as provided via "port work", e.g., to create a top-level temporary GIT repo so that I can easily get "diff"s to what's changed & then create a patch for those changes; I can tweak the build scripts and actual code to be compiled until it works in the ways I deem robust. Having an out-of-source build means I can just "rm -rf" the build directory and restart the build from scratch. One can, of course, "make clean" whether building in-source or out-of-source but that may or not do the trick depending on how well the CMake scripts keep track of build or modified files; "rm -rf" is -very- reliable at cleaning the build!

Summary: CMake out-of-source builds, at least in my opinion and experience, are not difficult to have well implemented from the project developer's perspective, and they benefit us developers trying to make ports as robust as possible. I wouldn't want it any other way!

Cheers! - MLD

On Thu, May 2, 2019, at 3:00 PM, Fred Wright wrote:
> But note that CMake's own default is *not* to build out-of-source (with 
> extra steps required when you want to), and not all projects build 
> correctly out-of-source.  So the PG default behavior is inconsistent with 
> CMake itself, as well as just plain not working in some cases, and the 
> poor discoverability of the option to change that (as well as the change 
> in the default from 1.0) makes that default even more undesirable.
> Also note that the benefit of out-of-source builds is negligible in the 
> MacPorts environment, anyway.
> Fred Wright

More information about the macports-dev mailing list