Blog FeedElectricAccelerator annotation files are a fantastic way to get a grip on your build behavior and performance, but what if your Build (capital B) spans more than one invocation of emake? Annotation gives you a good look inside any single invocation, but there’s no way to get an overview of the entire process. You can’t just catenate the annotation files from subsequent emake runs — the result won’t be well-formed XML, and the timing information for jobs in each subsection of the build will reflect time from the start of that subsection, not from the start of the logical build. Plus, you run the risk of having overlapping job identifiers in different subsections. What you need is a specialized version of cat that is annotation-aware. In this article I’ll introduce annocat, a simple Perl script I wrote for just this purpose, and I’ll explain how it works.
Read the rest of this entry »
Options
Annocat: e pluribus unum
May 27, 2009 — Eric MelskiUntangling Parallel Build Logs
December 1, 2008 — Eric MelskiI spend most of my time with ElectricAccelerator working on the “big” features — performance, scalability, fault-tolerance. It’s easy to forget that there are a ton of “little” features that can themselves make a big difference in the value of the system. Case in point: the build log. If you have any experience with parallel build systems, you know what a mess the build log becomes because you have any number of parallel commands all dumping output to a single logfile simultaneously. The output from each command gets interleaved with the output from other commands. Worse, the error messages get jumbled up too, so it becomes difficult to tell which commands are producing the errors.
I was reminded of this issue when it popped up again on the GNU make-help mailing list. Take a look at this recent post:
