pcb-rnd devlog

why glib is a bad idea

Levente tried to compile pcb-rnd on bsd and used a different c compiler than gcc. For this in the first step I fixed the build system so that it doesn't have gcc --std=gnu99 but gcc --std=c99.

And then everything broke. A minilib I use for hashing, genht, failed to link against hid/common/action.c. I first thought it was a bug in genht: genht was compiled without --std while the rest of the code compiled with --std=gnu99 or --std=c99. Genht heavily depends on static inline functions for performance, maybe that's why.

So I tried to reproduce the situation in a hello-world like program and tried all combination of --std, -DNDEBUG, -rdynamic and all build flags used in pcb-rnd for the genht lib and the test program, but all combination worked. It looked like it broke only in pcb-rnd.

I gave up on the minimal test case and went back to pcb-rnd. I realized if the build is the same, the only way it may break is that some header included before genht's headers change some global state. I started to shuffle the #includes. Long story short, it turned out if <glib.h> is included before genht's headers, it breaks.

Some more tracing showed it was because glib over-#defines the keyword inline in a public header that gets included from glib.h. It's all wrapped in a complicated tree of #ifdefs, so it behaves differently depending on the --std setting.

The morale of the story is... Well, I have multiple conclusions.

glib is not a lib that tries to solve something, it is a proggamming environment that tries to supersede C.
As such, it feels free to mess with the environment, redefine C keywords as it sees fit, because once you use glib, why would you use anything else? And once you use glib, you are programming in glib, not in "plain C".
Grepping through the pcb-rnd code, I see that pcb-rnd does not try to use glib as a programming environment, but needs only 2 and a half features: hash, list and rarely dynamic strings. Any other glib call is just a must that had to be done that way to get hashes and lists working.
genht is 510 sloc. I have a generic list implementation (which, by the way, is more efficient than glib's) It costs 256 sloc. So having type-independent hashes and lists in C89 costs less than 800 lines of code if you pick the right libs. Glib's include/ alone is over 24000 sloc! And in return glib breaks inline...

In a nutshell this is why I don't believe in glib-like solve-all megalibs. I don't say size alone determines this, but size is a good indication of potential problems.

If I need hash and lists and the offer is longer than 5k sloc, I know it will bring a lot of unneeded bloat that likely to break things.