Out-of-source build are a solution to a number of problems. Most pressing in my day to day work they make it efficient to maintain separate builds and jump back and forth between them; they reduce the frequency of committing things to the repository that have no business being there; and they make it possible to play nice with IT (source is backed up, build is not). As such, they are widely recommended by respected professionals (and I see few serious attempts to defined in-source builds), but they are not without their own problems.
The particular problem that I want to talk about today is build metadata. My work projects use CMake,1 which has two implications:
- Once configured the build system stores all the metadata
in
${BUILD_DIR}/CMakeChache - But you occasionally (::cough:: pretty regularly) have to blow the cache away and start over
Worse, for design reasons driven by a core dependency, the build of my main project needs a pretty complicated set of environment variables to configure.
No problem, though, the IDE will store that stuff for you, right?
Yes. Yes, it will. In a tool-specific file. In the build directory.
And yeah, you can .gitignore the IDE files so they don't get
committed, but because each IDE has it's own name, that's a little catalog of
names to maintain. Similarly, you can't reuse information cached by one tool in
another. It's be nice to have a unified standard for common things (build
locations, environment variables, etc) with some provisions for tool-specific
extras.
1 I know, I know. Don't get me started.
