Last week I sent out a broad last-rite email for a number of gkrellm plugins that my tinderbox reported warnings about that shows that they have been broken for a long time. This has been particularly critical because the current maintainer of all the gkrellm packages, Jim (lack), seems not to be very active on them.
The plugins I scheduled for removal are mostly showing warnings related to the
gdk_string_width() function called with a completely different object than it should have been called with, which will result in unpredictable behaviour at runtime (most likely, it’ll crash). A few more were actually buffer overflows, or packages failing because their dependencies changed. If you care about a plugin that is scheduled for removal, you’re suggested to look into it yourself and start proxy-maintain it.
I originally though I was able to catch all of the broken packages; but since then, another one appeared with the same
gdk_string_width() error, so I decided running the tinderbox specifically against the gkrellm plugins; there was another one missing and then I actually found all of them. A few more were reported ignoring LDFLAGS, but nothing especially bad turned up on my tinderbox.
What it did show though, is that the ignored LDFLAGS are just a symptom of a deeper problem: most of the plugins have broken
Makefile that are very poorly written. This could be seen in a number of small things, but the obvious one is the usual ”job server unavailable” message that I have written about last year.
So here’s a good checklist of things that shows that your
Makefile is broken:
- you call directly the
makecommand — while this works perfectly fine on GNU systems, where you almost always use the GNU
makeimplementation, this is not the case in most BSD systems, and almost always the
Makefileis good enough only to work with the GNU implemenation; the solution is to call
$(MAKE)which is replaced with the name of the
makeimplementation you’re actually using;
- it takes you more than one command to run
makein a subdirectory (this can also be true for ebuilds, mind you) — things like
cd foo && makeor even worse
(cd foo; make; cd ..; )are mostly silly to look at and, besides, will cause the usual jobserver unavailable warning; what you might not know here is that
makeis (unfortunately) designed to allow for recursive build, and provides an option to do so without requiring changing the working directory beforehand:
make -C foo(which actually should be, taking the previous point into consideration,
$(MAKE) -C foo) does just that, and only changes the working directory for the
makeprocess and its children rather than for the current process as well;
- it doesn’t use the builtin rules — why keep writing the same rules to build object files?
makealready knows how to compile
.cfiles into relocatable objects; instead of writing your rules to inject parameters, just use the
makeis designed to do! Bonus points if, for final executables, you also use the built-in linking rule (for shared objects I don’t think there is one);
- it doesn’t use the “standard” variable names — for years I have seen projects written in C++ insisting on using
CPPFLAGSvariables, well that’s wrong, as here “cpp” refers to the C Pre-Processor; the correct variables are
CXXFLAGS; inventing your own variable names to express parameters that can be passed by the user tends to be a vary bad choice, as you break the expectations of the developers and packagers using your software.
Now, taking this into consideration, can you please clean up your packages? Pretty please with sugar on top?