C++ can die screaming in a fire, preferably with the viciously beaten body of Make wedged underneath it.

For three hours today, I spent time debugging a crazy bug where a value held in a class field variable was correct in one function of the class, and garbage in another function of the same class with no assignments or buffer overflows in between. I wrote all sorts of debugging code and did nasty tricks with gdb to find out how that damn variable was changing from one function to the next.

When I found the source of the bug, it was one of those moments where I understood that I was dangerously straining against the clear and frail veil of sanity. I was absolutely positive that the lush verdant fields so tantalizingly close to my grasp were infinitely better than the burned out weeds at my feet. Upon "The Realization", the headache which pierced through my brain like a old man's car through a farmer's market splintered my will to live into pieces and scattered them across the permanently salted fields of primal rage.

It was a class declaration mismatch in object files. This happens when you change the structure of a class declaration, but only some objects using that class get recompiled. Some object files are using the old declaration of the class and others are using the new declarations. This causes the linker to pick an address for the field variables which is correct in some object files and wrong in others, hence leading to corruption simply at the call of a function. I'd say that this bug is actually worse than a memory corruption bug that is outside the ability of a memory checker program--because the declaration skew has no incorrect source code to discover upon inspection.

This was a classic case of a particular failure of Make. I typed make in a subdirectory of the workspace, and it didn't go back out and recompile the object file in another directory which should have been updated. Since I thought no one else was using the class declaration, it didn't occur to me to go back a directory and recompile. However, it shouldn't have to occur to me...

I looked at some make replacements and found a couple of note. Between SCons and Jam I'd choose SCons because the dependency language is also Python itself. Jam's language does look pretty rich, but having full Python (and its libraries) available to you edges SCons out over Jam.

However, it looks like SCons's autoconf-like functionality has been hastily grafted on and doesn't look too complete. If the functionality was extended to be at least a super set of autoconf, then SCons would be a pretty powerful tool. Sadly, autoconf's solution of producing a configure script really is a good one, because all UNIX machines everywhere have a Bourne shell on them. SCons is nice, but will some old and crusty hpux machine be able to deal with it? Probably not.

I wonder if there is an SConstruct to configure translator....

End of Line.