ats:
Response to a complaint made against the BBC by Southampton Solent University, after a report on the lowering of academic standards there.
One interesting complaint from the university:
"8. The allegation that staff felt under pressure from the management to pass students was unfounded."
If that's the case, then SSU must be secretly running a nuclear waste disposal facility in their basement, or something.
Every academic I've spoken to lately has felt that they're under pressure to pass students, because the way universities are funded is failing miserably under the load of new students caused by the increase in the number of people attending university.
It seems odd that the SSU management would deny this, rather than taking the opportunity to point out where the pressure's coming from...
ats:
"TEHRAN, Iran (AP) - Iran's hardline President Mahmoud Ahmadinejad called Tuesday for a purge of liberal and secular teachers from the country's universities, the official Islamic Republic News Agency reported in another step back to 1980s-style radicalism."
Ah, finally Iran makes a move that the Republican Party can stand firmly behind...
ats:
The Debian cdrtools packagers have finally given up trying to make sense of Joerg Schilling, and have forked cdrtools. So far, so good.
Unfortunately, they've chosen to use yet another wacky custom build system.
For those of you that haven't seen me ranting about these before, they're invariably horribly broken, making it seductively easy for developers to build their source, but hard-to-impossible for end users and packagers to actually install the software.
Examples of things that fall into this category that I've already spent a while banging my head against: jam (all three varieties of it), SCons, icompile, and fifty or so one-off systems that people have built into their packages thinking it was a good idea.
I wrote up a guide to making software packagable a while ago, which lists most of the traps these systems fall into.
Let's see how CMake fares...
Well, first off, unlike automake it's not included in the package; you need to install CMake separately. (I don't necessarily count this as bad, since I'm as fed up with 30 megabyte source archives as everyone else.)
So the first job is to package CMake itself. Hm. No automake stuff in evidence, but there's a configure script; so they've rolled their own custom configuration system just for CMake itself.
And, indeed, "configure" mangles its arguments and runs "bootstrap". But at least it figures out where the source dir is, so it doesn't break horribly if I do "work/foo/configure --help" like some systems.
Right, so I get GARstow to invoke the configure script with the standard args, and it grinds away for a while (compiling CMake from C++ source, it would appear), and dies with:
"CMake Error: This project requires some variables to be set, and cmake can not find them. Please set the following variables:"
"/gar/devel/cmake/work/cmake-2.4.3/Source/CURSES_INCLUDE_PATH /gar/devel/cmake/work/cmake-2.4.3/Source/CursesDialog/form/CURSES_INCLUDE_PATH"
Those look like mighty odd variable names for me, and setting them as environment variables does no good.
Neither is there any documentation on the web, other than (fortunately) the OpenPKG spec file whose author clearly had the same problem.
So the way you set a variable for CMake is:
SET(CURSES_INCLUDE_PATH "$(prefix)/include/ncurses" CACHE PATH "")
And that's got to be in a text file, which you pass using the --init arg to configure. Not really very friendly.
Now, that's my first glimpse of CMake syntax. How very weird!
Let's have a look at a syntax example from the FAQ:
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
COMMAND ${CMAKE_COMMAND}
ARGS -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c
)
Ah. Clearly this is the build system of Discworld's Death, since you have to TALK IN CAPITAL LETTERS ALL THE TIME. Hey, guys, it's the twenty-first century now; we aren't using teletypes any more...
That's also absurdly verbose syntax. Here's what that rule looks like in make:
foo.c: bar.c
cp bar.c foo.c
So I'm not entirely enthused about this system so far...
Right, now the configure step's finished, let's start the build.
Oh, that's rather cute: while it's compiling (using the Makefiles it's generated) it prints out a progress percentage before each line.
However, it's not printing the commands that it's invoking; previous experience has shown that this makes debugging build problems needlessly hard.
While I'm tapping my fingers waiting for the build (it's C++ -- so it'll take hours), here's a really scary example from the FAQ.
"The following code snippet illustrates how you can "pervert" the bibtex and latex generated auxilary files (.aux, .log, .dvi, .bbl...) to create an "artificial" set of CMake dependencies."
But why on earth is that necessary? Can you really not run multiple commands from a CMake rule?
The syntax suggests you can't...
If that's the case, then CMake's pretty useless as a build system -- pretty much any non-trivial Makefile will have rules that invoke multiple commands.
Eww. I've just looked at the CMakeLists.txt (silly name, by the way) for CMake itself. I didn't think it was actually possible to produce a language less readable than autoconf's configure.ac format, but no, these guys have done it.
Right, when I do "make -n install", all I get in the output is "bin/cmake -P cmake_install.cmake". That's not very encouraging or very useful.
It turns out it does work with DESTDIR, but there's no way of telling that without trying it...
Argh. And it's installing stuff in $(prefix)/doc by default. That's not FHS.
(Nor is $(prefix)/man, but that does at least exist on my system already...)
Incidentally, there are no GPG signatures for the CMake source archives. This is software that runs with admin privileges parsing untrusted data; it really ought to be signed.
OK, so now I'm building a package. I can set CMAKE_INSTALL_PREFIX as an equivalent of --prefix, but what's the equivalent of --sysconfdir, or --vardir?
Right, so the configure and build of cdrkit worked fine until it got to a file that needed a library that I hadn't installed. I installed the library, and the build still failed (because it wasn't trying to link against the library) until I did a "make clean" and started again. That's the sort of problem that new build systems should be fixing, not creating!
And again, for the generated build tree, the Makefiles are misconstructed such that "make -n install" doesn't work.
Right, CMake support added to GARstow, and cdrkit packaged. Conclusion: CMake's not as bad as some of the build systems out there, but it's still needlessly different from automake, doesn't include some of its functionality, and offers no obvious advantages for free software developers that I can see.
David: Pondering going to see this on Saturday night. Any interest?