26 Jan 2006 cinamod   » (Master)

I'm going to have to disagree with some of Raph's points about the auto* toolchain. While I can't say that I'm pleased with many of auto*'s decisions, I've yet to see a build system that attempted to fill auto*'s niche and fill it as well as auto* currently does.

  1. The project's original goals still are relevant. Maybe you don't care about toolchains other than the GNU one. But I (and more importantly, my customers) care about binaries being compiled with the native compiler and linked with the native linker. Face it, even GCC 4.x isn't as good performance-wise as most platform-specific compilers, and suffers from occasional ABI-related issues in places where it's not the platform's native compiler.
  2. Auto* does solve real-world portability problems, especially the Windows portability problem. For example, compiling in a MSYS/MingGW or Cygwin environment is trivial. At my current job, I was able to take a few million lines of C source code managed with auto*, add 2 lines to my configure.ac file for improved Win32 libtool support, add a reimplementation of mmap, and it all "just worked". Auto* is also capable of cross-compiling Win32 binaries from Linux platforms (workrave's Win32 nightly builds do that, for instance). I hear that it's even possible to use Microsoft's cl.exe and link.exe with auto*.
  3. Regarding error reporting, the errors it reports are only as good as the people who wrote the error messages. Because FooProject's author didn't write a good AC_MSG_ERROR or AC_MSG_WARN message, doesn't mean that it's not possible to do so or that their shortcomings are somehow the tool's fault. The tool is only as good as those who would use it.
  4. Regarding auto*'s tendency to work around deficiencies in ld/cc/nm/etc..., all I can counter with is "we don't control the horizontal and the vertical". Sure, it'd be great if problems were fixed at their root, or if they were never introduced in the first place. But please, let's be pragmatic. I live in the real world. Imperfect software gets produced all the time. And the support lifespan of a typical *NIX sytem can easily be measured in decades. Sure, there's timed/planned obsolescense, within reason. But there's a reason why people still code to C89 standards instead of C99. It's because that timed obsolescence is measured in similar decades-long increments.

Is auto* a perfect toolchain? No. Like you, I wish that we had a better alternative and feel that one is long past due. But in an imperfect world of having to support legacy linkers, compilers, and ancient platforms, auto* still fills a useful niche. Things are not as bad as you make them seem. You're just lamenting that the tools attempt to address a niche that you'd rather ignore entirely. That's fine for you. But writing off the tool entirely for those reasons is just sour grapes...

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!