Writing

Software, technology, sysadmin war stories, and more. Feed
Friday, March 30, 2012

Build system: change things or accept the status quo?

I must be on the right track with this build tool project, because now I'm getting "this won't work because..." feedback. Here's what I mean.

I heard from readers who mentioned using pkg-config. Indeed, pkg-config is a nice way to find out what the magic compile and link flags should be for a given package on your system. It might even make sense to have my build program try to look things up in there before demanding entries in its own .build hints file.

What doesn't make sense is adding far more layers to existing Makefiles just to be able to use this thing. It just takes you right back into the world of wrangling those files, and this is for simple, boring cases! The whole point of this was to make simple things simple by having them just work without all of that manual maintenance.

Elsewhere, apparently it is now surprising that users of my program will have to learn how the hints file works. Yes, there is going to be some learning involved. There's no way around it. I'm sorry if that's too strenuous. I'm not forcing anyone to switch their build systems here.

This is what I call offering an alternative and challenging people to re-think the way they do things. Calls to "let it be" and "just use what's already there" amount to "let's boldly go nowhere" and "sit down and shut up". In this case, I reject both. We've been going nowhere with this stuff for long enough.

The glimmer of hope here is that once this thing knows how to handle a given #include like "mysql/mysql.h" for your system, it can use that knowledge on any compatible project. You don't have to keep teaching it over and over again. You also don't have to worry about whether a certain project has bothered to check for that library.

Here's a very real situation: some project is developed largely on a particular Linux distribution. In that distribution, certain libraries and/or header files just work with the stock flags. Nobody has any need to go looking for them, so no autoconf detection magic is added. They live in ignorant bliss.

Then someone comes along and tries to build the project on another system where one of those libraries or headers isn't quite ready to go as-is. It's there, but you need some additional flags to find it. You have to identify this, and then try to figure out how to add it to their build process.

If they're using autoconf to generate Makefile from Makefile.in, you'd better not edit that Makefile. It'll just be overwritten the next time you run configure again. Also, be careful with that Makefile.in. Is it even the top level, or does something else create it? You'd better dig in and make sure you really understand the build system before trying to mess with it.

Assuming you get this figured out, now you can write a patch which adds the necessary magic and set up your build process so that you untar, then patch, then build. Now you get to submit that patch upstream and hope they don't call you an idiot for missing some subtle thing about how their code works. You also have to hope they accept it.

You get to remember this until it shows up in a release and you can integrate it on your end. Then you can undo your patch and go on with life... that is, until it happens with another project, since the root cause was never addressed.

This whole situation can come up over one stupid little switch.

You don't have to use this tool. It isn't really intended for those projects where you foist source code upon the rest of the world. It's really for the people who have a job to do with a large code base and are tired of the constant fiddling of metadata which is required to keep it in line. The programming world isn't all free software projects.

Besides, I tend to think of it as a obstacle for technical debt. You can't set up certain ridiculous situations because it just won't allow it. Remember the nutcase who did #include "foo.cc" instead of designing things to be testable without such hacks? If he had tried that with my build tool, it would have just laughed at him.

Think of it as a pre-emptive code review tool. You have to get past it before you can annoy humans with your cleverness.