6 ms·

I suppose this is the essence, because however much he may chaff at autoconf's implementation (and it surely is ugly), it actually works pretty well. Users (in

I suppose this is the essence, because however much he may chaff at autoconf's implementation (and it surely is ugly), it actually works pretty well. Users (in this case, "user" = "developer") never see the ugliness for the most part. With more open development communities there are tradeoffs, but often the result is that you can do stuff you simply wouldn't have the manpower to do in closed communities. I think most of us would love it if every library and tool we used was pretty and elegant, but in the end, it's often better to have something, however much you'd ideally wish for it to be prettier. Morever, a community in which different components are often the result of disparate teams with different thinking probably results in more attention paid to robust and simple interfaces between them, simply because that's the only way you can get everything to work. Systems composed of heterogeneous components with robust and simple interfaces between them, are, I think, a good thing. I suspect they tend to be more future proof than systems with everything designed by one person from the top down, because in the end, change is inevitable, so having to deal with heterogeneity from the beginning is an advantage.

bjourne 14y ago
No stop it! Don't defend autoconf, it is not worth it and the software does not deserve it. Users of autoconf, that is developers that try to use that POS to build their software definitely experiences its pains. It is not just that M4 is a horribly ugly, badly, inconsistent language. You also have about a million leaky caches in the build process to deal with. Autoconf rewrites the build scripts in three stages, each which is cached and also keeps an autom4te.cache directory around. So what happens is that you update something in the M4 build script and then have to spend hours hunting down why the change didn't change anything because some stupid autoconf cache wasn't flushed. What autoconf has done is to separate free software developers into two categories. Those who can hack the source (the .c and .h files) and those who understand the "autoconf magic." It should be telling that people refer to it as "magic" - it's a fing build system, not rocket science. The only reason this ugly piece of software has lived on is because people treat it as some kind of magical device and inertia. Configuring and building software is an easy problem. It gets even easier if you finally decide to drop support for 30 year old unices that no one uses. The autoconf team consistently refuses to do that which why the software wont ever become better. CMake, SCons, Waf and probably half a dozen more tools all do a much better job configuring software than autoconf ever will. People really need to try those alternatives and I'm sure they will realize autoconf needs to die, die, DIE.
- snogglethorpe 14y ago
  Shrug. You don't like autoconf, great; that's clear. As a user of it, I think it's sometimes ugly, but basically fine for its intended purpose (easing portability amongst POSIX-compatible systems). [If you like Windows, you're probably outside its target audience.] CMake, SCons, etc, all have their pros and cons. They are hardly paragons of virtue though. [Yes, even as a mere "consumer" of CMake (someone who occasionally needs to build packages that use it), I've been bitten and frustrated by it.] As far as I've found, there really isn't any build tool that really gets everything right -- which suggests that the problem is harder than you suggest. [Although judging from the number of people who try to write their own build tool (most of which languish and eventually die, but cause some pain along the way), it's clear enough that many people think it's a simple problem...] > autoconf needs to die, die, DIE Decaf?
  - bjourne 14y ago
    You sound a lot like my colleagues when I tell them why I much favor dynamic languages like Ruby and Python over Java. :) They listen politely to my arguments, then shrug their shoulders and go "meh, Java works fine for me". CVS users are the same when it comes to Subversion users who are the same when it comes to Git users. It doesn't matter for a "works fine" person how many faults their current tool has or how much smoother "your" tool solves all those problems, they won't listen. Logic doesn't work maybe because it is very hard for them to get used to something new. Maybe because if you haven't experienced any alternatives it is very hard to imagine that something could be better.

bjourne 14y ago

No stop it! Don't defend autoconf, it is not worth it and the software does not deserve it. Users of autoconf, that is developers that try to use that POS to build their software definitely experiences its pains. It is not just that M4 is a horribly ugly, badly, inconsistent language. You also have about a million leaky caches in the build process to deal with. Autoconf rewrites the build scripts in three stages, each which is cached and also keeps an autom4te.cache directory around. So what happens is that you update something in the M4 build script and then have to spend hours hunting down why the change didn't change anything because some stupid autoconf cache wasn't flushed. What autoconf has done is to separate free software developers into two categories. Those who can hack the source (the .c and .h files) and those who understand the "autoconf magic." It should be telling that people refer to it as "magic" - it's a fing build system, not rocket science. The only reason this ugly piece of software has lived on is because people treat it as some kind of magical device and inertia. Configuring and building software is an easy problem. It gets even easier if you finally decide to drop support for 30 year old unices that no one uses. The autoconf team consistently refuses to do that which why the software wont ever become better. CMake, SCons, Waf and probably half a dozen more tools all do a much better job configuring software than autoconf ever will. People really need to try those alternatives and I'm sure they will realize autoconf needs to die, die, DIE.

snogglethorpe 14y ago
Shrug. You don't like autoconf, great; that's clear. As a user of it, I think it's sometimes ugly, but basically fine for its intended purpose (easing portability amongst POSIX-compatible systems). [If you like Windows, you're probably outside its target audience.] CMake, SCons, etc, all have their pros and cons. They are hardly paragons of virtue though. [Yes, even as a mere "consumer" of CMake (someone who occasionally needs to build packages that use it), I've been bitten and frustrated by it.] As far as I've found, there really isn't any build tool that really gets everything right -- which suggests that the problem is harder than you suggest. [Although judging from the number of people who try to write their own build tool (most of which languish and eventually die, but cause some pain along the way), it's clear enough that many people think it's a simple problem...] > autoconf needs to die, die, DIE Decaf?
- bjourne 14y ago
  You sound a lot like my colleagues when I tell them why I much favor dynamic languages like Ruby and Python over Java. :) They listen politely to my arguments, then shrug their shoulders and go "meh, Java works fine for me". CVS users are the same when it comes to Subversion users who are the same when it comes to Git users. It doesn't matter for a "works fine" person how many faults their current tool has or how much smoother "your" tool solves all those problems, they won't listen. Logic doesn't work maybe because it is very hard for them to get used to something new. Maybe because if you haven't experienced any alternatives it is very hard to imagine that something could be better.