build-process

When running a CMake generated Makefile with multiple processes ( make -jN ), the output often gets messed up like this: [ 8%] [ 8%] [ 9%] Building CXX object App/CMakeFiles/App.dir/src/File1.cpp.o Building CXX object App/CMakeFiles/App.dir/src/File2.cpp.o Building CXX object App/CMakeFiles/App.dir/src/File3.cpp.o I'm not sure, but I think this behavior is also there for Makefiles not generated by CMake. I'd say it happens when multiple processes write to stdout at the same time. I know I'm probably being pedantic, but is there any (simple) fix to this? ;) Eric Melski If you're using GNU make,

Our project is a content management system supporting several dozen of our websites. The development group started off small and in one location, and we dealt with a fairly standard coding/deployment strategy. We coded off of trunk and insisted on a clean trunk. Every few days we would tag trunk and deploy to the test server. If all worked out, we'd deploy to Production and move on. That worked well for a while until the team grew. We frequently faced situations where the revision that was tagged had problems that needed to be fixed before going to Production. While the developer responsible

I love to organize my code, so ideally I want one class per file or, when I have non-member functions, one function per file. The reasons are: When I read the code I will always know in what file I should find a certain function or class. If it's one class or one non-member function per header file, then I won't include a whole mess when I include a header file. If I make a small change in a function then only that function will have to be recompiled. However, splitting everything up into many header and many implementation files can considerately slow down compilation. In my project, most

I have several projects that produce NuGet packages that I publish to an internal server. We're using semantic versioning , and using tags in our Git repository to control the version numbers. I'm tagging like this: git tag -a v1.0.0 -m "tagged" And, during the TeamCity build, I run git describe --long , which produces an output like this: v1.0.0-0-ge9c047d The fourth number in the output is the number of commits after the tag. The 0 here means that no commits have been made since the tag. I use these first four numbers as the version number (and, incidentally, the entire string as the

I would like to find a way to compile and package our iPhone application as part of our automated nightly build. At present we always have to manually kick off a build on a shared Mac that has the adhoc certificates installed on the box and then post the resulting test binaries some place where testers can pull them down and install them. Has anyone found an approach to automation that works for them? There's a command line tool to build Xcode projects: xcodebuild Try using xcodebuild, it'll build an Xcode project from the command line. You can then pull the binaries out of the build directory

During make, I create string fields which I embedded in the linked output. Very useful. Other than a complex sed / grep parsing of the git status command, how can I easily determine if files in the workspace have been modified according to git ? If you just want a plain “Are there any differences from HEAD?”: git diff-index --quiet HEAD If the exit code is 0, then there were no differences. If you want “What files have changed from HEAD?”: git diff-index --name-only HEAD If you want “What files have changed from HEAD, and in what ways have they changed (added, deleted, changed)?”: git diff