# Unfuck gettextize. grep -v '/dev/tty' < /usr/bin/gettextize > gettextize chmod +x gettextize # Patches affect Makefile.am and configure.ac, so rerun autotools. ./gettextize -f autoreconf autoconf
Personally I’ve never known a single pair of packages that cause more trouble than GNU gettext and autoconf. Probably together they have wasted thousands of years of human effort. Configure scripts probably cause extra power stations to be built.
Richard WM Jones 
Well, gettextize (or autoconf IMO) is not meant to be run all the time, but just once, with the results saved in the project’s source tree. It does seem a bit wacky to prevent it being run mechanically with that /dev/tty stunt though.
Apparently you’re supposed to use autopoint instead of running gettextize. Except that’s not documented, nor does it work.
autopoint requires that you hard-code the version of gettext into the configure.ac file. Really — it completely refuses to run if you don’t do this. So you have to add something like:
Nevermind that it’s insane to hard-code a specific version. Which version should you hard-code? Don’t choose an unavailable version, because then your code won’t compile at all on some platforms (notably, there is no common version we could use on Fedora, RHEL and Ubuntu).
Upstream autopoint lets you override this nonsense with the -V option, but in RHEL 6 the -V option is commented out of the source of the program.
So we’re back to using gettextize and removing the stupid by hand.
> Well, gettextize (or autoconf IMO) is not meant to be run all the time, but just once, with the results saved in the project’s source tree.
And that’s the EPIC FAIL, right there. Generated files have no business being in a SOURCE tree!
I see the dogmatic purity in that, but OTOH you can see some pragmatic problems being pointed out right here.
Those “pragmatic problems” are all fatal design flaws in autocrap. CMake works just fine without bundling any generated files in the source tarballs.
“Don’t choose an unavailable version, because then your code won’t compile at all on some platforms (notably, there is no common version we could use on Fedora, RHEL and Ubuntu)”
This type of problem would be mooted if the autoconf-generated files were checked into the source tree. Then no version on fedora/rhel/ubuntu would be needed, just to build.
Yes, but it’s pretty gross. And why should I have to do this for gettext? There is literally no other library I have ever used which is so obscurantist as GNU gettext. There’s nothing much special about gettext — it’s a library and a program that you run over the source, end of story. No need for complexity here.
True. But gettextize is different. It “prepares a source package to use gettext”, as in adjusting the build infrastructure. If you are doing this just to regenerate the .po/.pot files, you don’t need to run gettextize for that at all, but rather xgettext and msgmerge. (The output of *those* programs can also be checked into the source tree.)
It’s done here because we patched configure.ac in the spec file, so we need to regenerate it, and autoconf barfs unless we run autopoint/gettextize again because the version of gettext used upstream is different from the ancient one used in RHEL. Edit: And what other library provides scripts that have to run in order to alter the build structure of your program???
“It’s done here because we patched configure.ac in the spec file, so we need to regenerate it,”
I see. In the auto*-generated-stuff-in-git scenario, if the spec file had to carry a patch, it could patch both configure.ac *and* configure, so again no auto* execution would be required during the build. (Only the person who writes the spec patch would have to have used the sameish autoconf* versions as upstream.)
And that’s highly impractical. It’d mean you’d probably have to regenerate all the diffs at every single new upstream version. (Diffs of generated files tend to carry a lot of irrelevant changes which are likely to conflict, even for a one-line change in configure.ac. If you cannot find the exact version of each autocrap component upstream used (which is usually a patched distro version; in any case, the exact same version is unlikely to be packaged in your distro), there will be even more bogus changes.) Plus, autocrap doesn’t trust people to regenerate what needs to be regenerated and thinks it has to check the timestamps of everything and regenerate random stuff which it thinks is “outdated”, and then complains (with hard errors) about mismatched versions, which makes patching generated files highly unreliable.
> Personally I’ve never known a single pair of packages that cause more trouble than GNU gettext and autoconf.
+1, autocrap sucks!
Fortunately, there’s an alternative. http://www.cmake.org/
I knew someone was going to say that. CMake also sucks, differently to be sure.
You keep saying that. You never say how it “sucks”. CMake doesn’t have any of the issues you describe. Adding gettext translations in CMake doesn’t require bundling any generated build scripts. At most you bundle .pot files, and even that is optional.
I’ve actually used cmake quite a bit, and my problem is not that it’s more or less broken than autoconf, but that it doesn’t fix the brokenness of having a configure-like process in the first place.
Specifically, I still have to write a script that tests for the things I need, when:
Basically there is nothing that does the right thing (ie. items (1) and (2) in the list above).
ad 1: Huh? I read the whole documentation blurb of redo and I don’t see ANYTHING redo does implicitly, you have to code it all explicitly. And what information that “is already implicit in the source code” do you have to spell out in a CMake file? (Note that makefile dependencies of object files on the header files their source file includes are automatic in CMake!) And redo really looks no better to me than autocrap. Slow implementation languages (Python and shell), overuse of shell (which also implies poor portability to non-*nix systems such as Window$), encouraged bundling of build scripts (that “do” script which doesn’t even handle dependencies).
ad 2: First of all, that’s your bias from coming from functional programming speaking here. It’s not an objective requirement. And secondly, make is more declarative than a build.sh (dependencies are declared in a declarative way, make decides by itself in what order to execute the snippets, which is what allows -j to work), and CMake is more declarative than make (because you don’t normally code the imperative snippets anymore either).
ad 3: Here you’re criticising autocrap and praising CMake, which would be quite off the point, if it weren’t for your CMake praise being incorrect. (CMake is single-threaded, just like autoconf’s ./configure scripts.) What CMake does save you is the pain (and non-parallelizability) of pregenerating files, you only invoke cmake at configury time.
ad 4: That’s a good thing: C++, a fast compiled language, is a great implementation language, and the CMakeLists language you call “half-arsed” is much better suited to the task and thus much easier to use than some repurposed general purpose language like m4 (which autocrap uses, or shell as in redo).
Apparently “redo” isn’t the project I was looking for. But anyway, configure requirements are implicit already in the code. If I write
#include <gettext.h>then I’ve expressed that I need that library, and if I remove the same include, I don’t need it any more. There’s no need for me to write that over again in a configure.ac or CMakeLists file.You can extract all this by looking over the source or using LD_PRELOAD (see my own project auto-buildrequires for a demonstration).
My preference for declarative languages isn’t anything to do with functional programming. It’s because it’s vital for parallelizing these tests (any remaining which cannot be extracted automatically from source). Makefile is more like a dataflow language than a declarative language, but it does at least demonstrate easy parallelization.