begin quoting John H. Robinson, IV as of Sat, Aug 19, 2006 at 01:41:07PM -0700: > Andrew Lentvorski wrote: > > Today I got an error trying to compile Amarok. No big deal, right. > > Just fix the libraries and move on. > > You listed C in the subject, and never once talked about it. What is > wrong with C? > > I agree with Autoconf/Autotools. Very baroque. I don't care much for it. > C++ I do not care for, because it seems to break all the time.
Autoconf and friends seem wonderful when the work, and are generally a PITA when they don't. The alternative seems to be something like imake or a language/compiler that takes care of dependency issues. C++ is just... nuts. > C itself is mostly fine. The prepocessor may be a a bit whacked, but it > is relatively mindless. Nearly all C madness I attribute to the preprocessor. Restrained, careful, sober use of the preprocessor is required, plus some hanging out in dark alleys to apply the stick of correction upside the heads of those programmers who enjoy doing clever things with the preprocessor. That being said, there are a lot of areas where C doesn't seem appropriate. GUI _applications_, f'r instance. > I don't use KDE nor GNOME because of the whole huge chain of odd > dependencies, both when building and running. Start up a single GNOME > program, watch what else gets started for seemingly no apparent reason. > It boggles the mind. Makes it hard to keep track of what /should/ be running on one's machine. > Make, again, I have little problem with. Autotools and Autoconf use > recursive make, which can be quite harmful, and can break builds done > out of order. Simple makefiles are fine. Much better than compiling all the source files at once into a.out -- but when the auto-* tools come and play, makefiles are turned into faux-programs in and of themselves. Bleah. > Such as, you are trying to hunt down an error i na suport library in > a subdirectory, so you cd into it and invoke make. It can't, because > there is another dependency that it can't resolve because of the > recursiveness. If it builds, you still may not have something > workable as some other part may have affected the build in odd ways. Um... if I'm hunting down an error in a support library, I should have presumably compiled everything already before I make my change. When I make a change, I should compile that code immediately, yes? The problem is when I change an interface, and some _other_ code depends on the code I've just modified... but I don't want to invoke _that_ compile just yet, as I (a) don't know if my changes will compile, and I (b) don't know if my changes will pass the regression/unit tests, and (c) I may not be done making those changes. _Hopefully_, the code has been modularized in such a way so as to reduce the amount of coupling between modules, thus minimizing the breadth of recompiling necessary. If module A is strongly coupled to module B and vice-versa, then there really isn't two modules. > Basically, if I see something using recursive make I will, after > fixing a problem, make a clean build tree, apply the fix, and then > run make from the top. I do not trust clean or distclean targets. > Thank goodness for lndir. Even with a non-recursive make, a "make clean ; make" should be done every now and again. I've seen projects where the first compile fails, and the second succeeds. Or the fourth finally succeeds. You can get dependency-hell in a non-recursive makefile just fine. :-/ [snip] > I look forward to your next weekly column :) Heh. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
