November saw the release of Fedora 14 which includes the new and improved GNU make 3.82, this includes some fixes for long standing bugs in the parser – and therefore breaks dozens of projects’ Makefiles.
Common signs of the new, strict, make are the following output at make time:
Makefile:246: *** mixed implicit and normal rules. Stop.
This means you have both explicit and pattern targets in your make rule, this caused issues if explicit targets where used in the rule *after* pattern targets make could misparse the entire rule – of course, make had been doing this for long enough that everyone knew to avoid doing that…
Makefile:923: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
Make has always required tabs, rather than spaces, for indentation. But in previous versions of Make it was permissible to use 8 spaces instead of a tab. This is no longer allowed in make 3.82!
Whilst the Makefiles of most projects have been updated we where bitten by this pretty hard where our stable release of Poky Laverne 4.0, released October 26th, can’t be built on Fedora 14. Ouch!
So this week, I donned my distribution engineer hat and set about resolving these issues, I had to hack the Makefiles of some dozen or so projects (and even did some guerilla pushes to Gnome git).
The need to do this has left me extremely frustrated, these bugs have existed in the parser for long enough that they had been widely relied upon in many projects – to ‘fix’ the parser and therefore break the Makefiles of so many projects feels like a pretty severe move to me. Could this not have been a warning in make 3.82 and turned into an error later?
This is the second case of upstream introducing regressions that have hit us in Poky recently, the first being an regression in Python 2.7’s xmlrpclib which changed the way some private methods worked (parse_response() would no longer accept a file-like object) breaking our XML-RPC server…
Unfortunately this bug was not fixed for Python 2.7.1, but has since been fixed upstream.
Whilst I’ve ranted here I do really appreciate both of these open source projects and my knowledge with both Makefiles and Python programming has increased whilst debugging and working around these issues for Poky. There’s still a part of me that wishes I hadn’t had to do it, though!
I recently purchased some rail tickets online and arranged to collect them at a station I was to be passing through. Of course I forgot as I passed through said station so the other day I tried to go and collect them.
It really shouldn’t have been hard, I’ve done it several times before, you just go to the station from which you’ve arranged pickup and insert your credit|debit card into the collection machine.
Only this time it wanted a reference number. I vaguely remember being given one of those and told I would need it to collect the tickets. Bother.
Today I headed back, inserted my card, tapped in the reference of the first ticket. Boom. Tickets printed.
Round two, insert card again. Boom. More tickets! Wait, what?!? No reference number this time? …
That’s right – you only need to enter the reference number when you have more than one set of tickets to collect. Rubbish!
Is this really the best they could do? I’m certain I’m not the first to encounter this flaw in the system design, and surely I won’t be the last.
I can understand the potential use case where users only want to collect a certain set of tickets, leaving others for collection at a later date, but when your input method is a touchscreen UI asking the user to enter a reference number seems like perhaps the worst way of choosing which tickets to print.
What a load of pants!