8 ms·

Stop the autoconf insanity – Why we need a new build system (2003)

55 points by ahomescu1 13y ago

soulcutter 13y ago
Over 10 years later, and this is still relevant. It's scary how entrenched 'good enough' solutions become.
- brigade 13y ago
  It's also kind of amazing how terrible most of the replacements people developed are. Some are significntly worse than autotools, which is no mean feat. I blame make's awful syntax.
  - jjoonathan 13y ago
    Yes! But I'm not so sure we can entirely blame the make syntax. Something made the CMake people believe that inventing a new macro language / m4-redux was a good idea. I'm thinking that either m4 is a mind-virus or they're serving wine in lead glasses at the annual build-system conferences.
    - fragmede 13y ago
      Or; a build system is harder than it seems. Makefiles work fine in the trivial case, the problem is that things quickly become complex. Automating that complexity seems like it should be easy but, as it turns out, it isn't.
      - jjoonathan 13y ago
        Is there something about the (admittedly very difficult and thankless) task of automating builds that justifies re-inventing the wagon-wheel of languages? Because that was my specific complaint, and there's a reason why it was specific.
        fragmede 13y ago
        Because it seems easy. And easy things done "wrong" require re-invention. There should be a way to $FOO. Well, there's a way to do it in a Makefile but figuring that out is harder than should be, and doesn't make sense when you finally do figure it out. "Well that way is stupid. Here's how I'd do it:"
    - bch 13y ago
      CMake started for needing a suitable build system for a medical visualization application[0][1] that Kitware was working on, iiuc. How they could be using Tcl (an established, purpose built embeddable scripting/control language) in the Insight project, come to the conclusion they need a custom build system, and then when it comes to a control language decide to roll their own is a mystery to me, and a dropped ball, as far as I'm concerned. I like cmake, and used to use it exclusively, but after running into so many issues with their homebrew scripting/configuration language, I've mostly moved on. I wouldn't be surprised if I end up coming back, and I'd encourage everybody to give it a shot (the ease of typical simple Makefile generation, but with extra muscle), but the omission of Tcl as a control/config tool has always baffled me. [0] http://en.wikipedia.org/wiki/CMake#History [1] http://en.wikipedia.org/wiki/Insight_Segmentation_and_Registration_Toolkit edit: formatting
  - plorkyeran 13y ago
    s/Some/All/ I hate using autotools, but every time I touch a project that uses something else (and that is too complex for a ten-line Makefile), I inevitably end up wishing that it used autotools. I suppose it shows that sometimes a few decades of polishing a turd does sort of work.
    - krasin 13y ago
      what's about cmake?
      - cleversoap 13y ago
        CMake is interesting because the CMakefiles are just a different type of editable/configurable build script (ie. slightly different Makefiles). It's still an interpreted step between build instructions and the output that you actually use to build which isn't meant to be edited and therefore obfuscates part of the process... so autoconf. This is both a strength and weakness in that there are so many external modules for CMake (eg. the various FindX) that they work great most of the time but when they break they are more difficult to fix than an atomic change to the actual compiler flags in a Makefile. I don't think there will ever be a standard build tool, simply shunts to get the needed functionality from others. Eventually all build tools will exist in each other and the only interface will be recursion.
      - plorkyeran 13y ago
        CMake has the nice property of being able to generate non-Make build systems, but otherwise is more of just "autotools done differently" rather than "autotools done better". In practice I haven't found it to be any more pleasant to use than autotools.
      - CCs 13y ago
        So far CMake served us well. I'm using it for 8 or so years now for small and larger systems. I especially like that one file allows me to develop on XCode, somebody else on Visual Studio and finally deploy on Linux/gcc. One config file creates native projects on all 3 platforms, no manual hacking.
      - 13y ago
  - mansr 13y ago
    Most of the so-called modern build tools avoid make entirely, so its syntax cannot be to blame for their miserable quality.
    - deleted 13y ago
      [deleted]
    - brigade 13y ago
      I was thinking more along the lines of if writing for sh and make were less painful, then fewer developers would accept using such awful build systems instead. Autotools included.
      - mansr 13y ago
        I find neither sh nor make particularly painful. Python, however, I cannot stand the sight of.
- ChuckMcM 13y ago
  I don't know about this. Back in 2003 I got all spun up on scons, and later working at Google and their Build system which was pretty amazing in what it could do. At the same time I discovered that you can't run Windows software, PC hardware, and a Windows OS that are skewed by more than a few years (seriously true for games, less true for productivity apps). And yet I can download thttpd and type 'make' in the directory and it just builds. I've concluded that you can either embrace highly complex evolving systems and build tools which follow that evolution in such a way as to provide functions. Or you can make "point in time" sorts of things that are ephemeral in their ability to do what they do. Not a good choice but the only two that seem to be durable. I completely agree that it is a challenging place to be.
jamesjporter 13y ago
it's interesting how some software problems have garnered many really good solutions while others are still mired in stuff like this. e.g. no matter what your preferred source control tool is I think we can all agree that there are some pretty good options out there these days. compare that to the insanity that prevails in packaging in every corner.
- mturmon 13y ago
  Text editors are another classic example of this conundrum. Some problems seem to attract problem-solvers, and some do not.
  - jjoonathan 13y ago
    I don't follow. We've had TextWrangler, SubEthaEdit, TextMate, Sublime Text, and Smultron alongside rapidly improving IDEs like Coda, XCode, VS, LightTable, and a host of web-based environments like JSfiddle, Cloud9IDE, and Codepen. Text editors don't just attract attention, they attract a lot of attention, and I'm glad for it.
    - mturmon 13y ago
      I have used Emacs and vi since the 1980s, and view this differently. A lot of the work you refer to was largely duplicative. Of course, I'm not talking about IDEs or web-based editors. You're right though, I do enjoy the innovation in web editors.
      - jjoonathan 13y ago
        First of all, drawing a line between IDEs and text editors is a surefire way to ignore the kind of innovation that is happening with regard to text-editing. If you insist on doing this then in your search for innovation you've drawn a box so narrow that you should not be surprised to find nothing in it. There are only so many pure text-editing actions with positive ROI and E&V mastered the bulk of them long ago. Even so, E&V haven't been standing still. It's true they refuse to innovate in certain directions: 1. Out-of-the-box integration with modern toolsets (0-configuration documentation, smart autocomplete, build, debug, jump-to-definition, etc) 2. Present an interface that is easily discoverable by GUI-minded folk 3. Take advantage of the opportunities afforded by non-textual displays but each of these is done "poorly" in E&V for a good reason, as per your text editor / IDE distinction. They can't change these things without stepping on the toes of their power users (i.e. all of them) and leaving behind part of what made them great, which is why this kind of innovation is happening away from E&V. Most of the apps I listed address between 1 and 3 of the above issues. Just because the young upstart editors don't support keyboard input and customization with the fluidity of E&V doesn't mean they are purely derivative. They do something that a lot of people want done that E&V don't do, and they do it well. That's what innovation is all about. So I ask again what it is that you would consider innovation and why the projects I listed don't count.
stefantalpalaru 13y ago
> Joe GNU/Linux User has just downloaded and untared this package. Regular users are not supposed to install software like this. The only sane way to administer a distribution is to make sure everything passes through the official package manager. This leaves the developers and package maintainers to deal with autotools and I don't hear them complaining (very loud[1]). Autotools is simply good enough for the job and instead of being some sort of hated legacy it's being sometimes preferred for new projects (cough [2] cough). [1]: https://blog.flameeyes.eu/tag/autotoolsmythbuster/ https://blog.flameeyes.eu/tag/autotoolsmythbuster/ [2]: https://github.com/stefantalpalaru/vala-skeleton-autotools https://github.com/stefantalpalaru/vala-skeleton-autotools
- ahomescu1 13y ago
  Not every user has root/sudo access so they can install software system-wide (it's even arguable whether they should, instead of keeping those programs user-local).
- Sheepshow 13y ago
  Software freedom is the ability to do whatever you want with the code, for example, compiling it. I'm not saying there's any sort of license violation here, but it's not in the spirit of software freedom to "not supposed to install software [from source]"
  - stefantalpalaru 13y ago
    Granted, but the freedom to ruin one's system is not a freedom I would promote. Installing software from source is a good thing, you just need to go through the intermediate process of creating a package for your distribution first.
- chomp 13y ago
  In a perfect world, every single piece of software ever written is in every single distribution's package manager. This is not always the case in reality, however.
  - 13y ago
nathell 13y ago
The comment "Put the blame where it belongs: Automake" below the original article sums it up pretty succinctly. Quoting: All the complaints in the article are PRECISELY the kinds of complaints that autoconf programmers worked very hard to avoid. For example, it's IMPOSSIBLE to have version skew with autoconf because the configure script is completely pre-generated before being shipped. As far as the user is concerned it's a simple sh script. ALL of these problems stem from the "automake" monstrosity that creates many more problems than it ever solved. Unfortunately people now tar autoconf with the same brush as automake and libtool whenever they run into problems with these. Sigh.
- sehugg 13y ago
  I'm seeing some projects shipping without configure which is annoying.
- MichaelMoser123 13y ago
  For my projects I did a make system that uses gmake meta programming to easily define rules for most cases, here you have to includes a template make file that expands the target definitions into make rules. http://mosermichael.github.io/cstuff/all/projects/2011/06/17/make-system.html http://mosermichael.github.io/cstuff/all/projects/2011/06/17... The catch is of course most cases ; other stuff is still possible to do , but things become hacky. Another downside is cross compilation, my system does not do this effectively (though it works for Linux i686, x86_64 and Cygwin - many surprises between these setups !). Most build systems I know don't support cross compilation - except for automake, the terrible. If you do debian packages then you are strongly encouraged to use automake - because of cross compilation.
caf 13y ago
He again does the typical thing and runs "./configure --prefix=/opt". The configure script runs for a while, then exits with an error which basically translates to "You have an autoconf version which is three weeks old; please upgrade", but this is displayed in the most cryptic manner possible. This is simply incorrect. If you already have a configure script, then you don't need autoconf installed at all, let alone a particular version of it. autoconf is used for generating the configure script, not running it.
- ArbitraryLimits 13y ago
  I'm positive that I've seen configure scripts that try to check whether they, themselves, are out of date, and regenerate themselves if so. That's the only time I've seen an error about autoconf version skew. To be fair, I've only actually seen this on scripts I was writing - never seen it happen to something that passed make dist.
  - plorkyeran 13y ago
    Automake will regenerate and rerun the configure script if configure.ac is newer than configure, which is normally only the case if you're either modifying configure.ac or if the files are packaged incorrectly (and automake makes packaging a release correctly easy).
  - kelnos 13y ago
    I don't remember exactly (my autoconf/automake-fu has gotten weak these past years), but there's a macro AM_MAINTAINER_MODE that will add --enable/disable-maintainer-mode as an option to your configure script that will determine if rules get added to the final Makefile that will check to see if Makefile.am is newer than Makefile.in or if Makefile.in is newer than Makefile, or if configure.ac is newer than configure (etc.) and then attempt to regenerate them. I don't quite remember what the default is if you don't include AM_MAINTAINER_MODE in your configure.ac. So yes, you could have indeed seen that happen, but there are ways to make it not happen.
skywhopper 13y ago
Interesting that the alternative tools mentioned in the article (SCons, Cons, and A-A-P), only SCons has been updated since 2003 (according to Freshmeat), and its last update in 2010 appears to have been mainly to redo the version numbers and drop Python 2.4 support.
- bjourne 13y ago
  https://code.google.com/p/waf/ https://code.google.com/p/waf/ is the spiritual successor to SCons. It started off as a fork of it (due to performance problems in SCons) and then became a full project on its own. It can do everything autotools+make can and you only have to code your build in Python rather than Makefile + M4 + shell scripts. I've been using it for many years and it is technically superior to any build system I've seen. Shame the author of it doesn't market it more -- with some hype it would easily have been the de facto standard build system by now.
  - csense 13y ago
    Yeah, scons looked well-designed when I encountered it in 2012 or so, but it also looked dated and unmaintained. Good to know someone's picked up the torch.
  - mansr 13y ago
    Replacing make with python is a huge step back. The makefile language is simple yet extremely powerful for describing a dependency tree such as that for building an executable from sources. Its perhaps strongest point is that it completely agnostic to what the different steps actually do rather than consist of a predefined set of canned rules/tasks with, if you're lucky, a convoluted way of adding your own using e.g. python (or worse, java). This means that as long as a shell command can turn a set of inputs into an output, describing it takes (usually) just two lines of makefile, one naming the target and prerequisites, one providing the command to perform the transformation. If a particular rule is too complicated for a few shell commands, invoking a separate script (or even a just-built executable) is trivial. Every other system I've looked at needed a comparatively enormous amount of code for adding even the slightest tweak to the built-in rules. GNU make is actually two different languages coexisting in the same file (the makefile), a declarative language for describing the targets and their dependencies as well as a functional language for the variables/macros. Once you realise this, a whole new world of possibilities opens up. If more people took the time to actually understand proper use of makefiles, perhaps we'd see fewer poorly reinvented wheels.
caitp 13y ago
https://xkcd.com/927/ https://xkcd.com/927/ But on a serious note, I really want to see Gyp become more popular, for the simple reason that integrating multiple Gyp projects is essentially zero-effort. It's a beautiful way of working, even though Gyp certainly has room for improvement.
- ahomescu1 13y ago
  AFAIK, Gyp's biggest user is Google (Chromium uses it, and maybe others). Are there any non-Google projects that use it?
  - caitp 13y ago
    In addition to the big google projects using it (Chromium, V8, WebRTC/jingle, etc), there's also Joyent's Node.js (and forks, + numerous node packages containing native code), as well as numerous private projects that I've been involved with. Unfortunately, it hasn't taken off too much in the open source community apart from the above mentioned big name projects. Better documentation and more visibility could probably make that happen, though.
sparkie 13y ago
We don't need a new build system, we need a new mentality. The problem with build systems is they don't cover the entire scope required to actually build software reliably. Ideally, you want to take just your code as input and produce a target, but the reality is that you're taking your code, plus an environment with potentially infinite number of configuration options, and you're asking the build system to produce a target. This is effectively saying "Here's some code and some shit, please do your wizardry and make me something that looks like this." Is it any wonder that every proposed solution to this difficult (impossible?) problem gets it wrong? The correct solution is to declare the target you want, then build up the dependencies you need as input to meet that target and declare them explicitly, then perform the build in that isolated environment to ensure that no undeclared configuration options can alter the result of the build. This is what Nix (http://nixos.org/nix/ http://nixos.org/nix/) does, and by derivation, Guix (https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/), and Debian's ReproducibleBuilds is also attempting. The build process becomes effectively a pure function, free of unwanted side-effects. Nix doesn't actually perform builds in itself, except for trivial ./configure && make. It piggy-backs on existing build systems via bash scripts if needed, but it completely manages the environment in which such script will run, so it has local-side effects which are controlled, similar to how you might use the ST monad in place of IO in Haskell perhaps. I find Guix a bit more interesting because it can take on the whole problem - including the build system. While it can piggy-back on existing build systems in the same way Nix can, you can also write your own in Guile (or some other language and invoke from Guile). It doesn't really make sense to depend on the old cruft under this new mentality, because things like pkg-config are obsoleted by known, explicitly declared dependencies. The build process can be simplified (and probably sped-up).
- _delirium 13y ago
  How portable is nix? I haven't looked into it much, but from a (possibly mistaken) first impression it looks more like a replacement for yum or apt than for autotools. Despite being crufty, what I find valuable about autotools is that, given one source directory, I can successfully compile and link the package on many things: various distributions of Linux, the BSDs, Solaris, HP-UX, AIX, OS X, nearly whatever else you care to dream up. Does Nix actually do that (or target it, if not yet)?
J_Darnley 13y ago
Last time I built anything that required one of these autotools monstrosities, which was LAME I might add, it gave me some obscure error about not having a suitable type for a signed 64-bit integer. Which was unbelievably stupid since it had just "found" uint64_t for its unsigned counterpart. So I opened its nearly megabyte sized, thirty-two thousand line long configure file to track down the problem. I seem to recall that in the end I fixed it by correcting the placement of some braces around it many nested ifs to fix it. Now I avoid anything that needs anything like these tools or anything that has a step before running configure from a source code checkout.
dventimi 13y ago
Running "./configure && make && make install" usually results in a working installation of whatever package you are attempting to compile. followed by the auto tools are constantly a thorn in the side of users and developers alike. Which is it? Do the autotools "usually [result] in a working installation" or are they "constantly a thorn in [our sides]?"
- mateuszf 13y ago
  Usually in that case is not enough. Developer is potentially dealing with big number of users. Even a small percentage of people having problems with build is being a very suboptimal situation.
mschuster91 13y ago
I don't have many problems with the auto* toolkit. Yet, there is one problem which has cost me lots of money for buying beer and getting myself filled up: why can't auto* check for all libraries and then output an aggregated "libx,liby and libz missing, libfoo outdated" instead of the configure - apt-get - configure - apt-get cycle?
- andrewflnr 13y ago
  Because it's just a bunch of macros. To create an aggregated list, they would all have to, instead of printing out what they want, add their info to some global variable, whose name they all agree on in advance and probably with some kind of standard format. Which isn't to say it couldn't be done, but it would be much more complicated.
  - mansr 13y ago
    It wouldn't take much at all to have the AC_ERROR macro append the message to a global variable, set a global error flag, and continue. At the end of the script, if the error flag is set, the aggregated error messages would be printed. The variable names would only need to be coordinated between AC_ERROR and one other macro called at the end.
oakwhiz 13y ago
I'm surprised there has not been any mention of Gitian, the build system used by Bitcoin to perform exactly deterministic builds. The purpose of this is to enable multiple developers to prove that they are all signing the same binary. http://gitian.org/ http://gitian.org/
dror 13y ago
That's an old school build approach (it was 2003). The modern approach is: apt-get install (or your OS equivalent). It's 2014. I can't remember the last time I needed to install a package from source. Worst case scenario I need to add a repo.
deleted 13y ago
[deleted]
fsloth 13y ago
As build systems go, this seems like a promising experiment: http://sourceforge.net/p/meson/wiki/Design%20rationale/ http://sourceforge.net/p/meson/wiki/Design%20rationale/ tl/dr: -DSL for builds with well defined semantics, leverages existing toolchain -design constraints for the system that make sense, i.e. speed, portability, usability and common sense -does not try to reinvent the wheel but rather simplify the usage of existing tools - the build config it generates on my Ubuntu box seems to really deliver on the speed promise - I have no benchmarks to quote but a small c++ codebase using all sorts of dependencies including boost compiled nearly instantly
dschiptsov 13y ago
There is nothing wrong with autoconf or libtool. Take a look how sane developers (nginx, cpython, etc) are using it.

55 points by ahomescu1 13y ago

soulcutter 13y ago

Over 10 years later, and this is still relevant. It's scary how entrenched 'good enough' solutions become.

brigade 13y ago
It's also kind of amazing how terrible most of the replacements people developed are. Some are significntly worse than autotools, which is no mean feat. I blame make's awful syntax.
- jjoonathan 13y ago
  Yes! But I'm not so sure we can entirely blame the make syntax. Something made the CMake people believe that inventing a new macro language / m4-redux was a good idea. I'm thinking that either m4 is a mind-virus or they're serving wine in lead glasses at the annual build-system conferences.
  - fragmede 13y ago
    Or; a build system is harder than it seems. Makefiles work fine in the trivial case, the problem is that things quickly become complex. Automating that complexity seems like it should be easy but, as it turns out, it isn't.
    - jjoonathan 13y ago
      Is there something about the (admittedly very difficult and thankless) task of automating builds that justifies re-inventing the wagon-wheel of languages? Because that was my specific complaint, and there's a reason why it was specific.
      - fragmede 13y ago
        Because it seems easy. And easy things done "wrong" require re-invention. There should be a way to $FOO. Well, there's a way to do it in a Makefile but figuring that out is harder than should be, and doesn't make sense when you finally do figure it out. "Well that way is stupid. Here's how I'd do it:"
  - bch 13y ago
    CMake started for needing a suitable build system for a medical visualization application[0][1] that Kitware was working on, iiuc. How they could be using Tcl (an established, purpose built embeddable scripting/control language) in the Insight project, come to the conclusion they need a custom build system, and then when it comes to a control language decide to roll their own is a mystery to me, and a dropped ball, as far as I'm concerned. I like cmake, and used to use it exclusively, but after running into so many issues with their homebrew scripting/configuration language, I've mostly moved on. I wouldn't be surprised if I end up coming back, and I'd encourage everybody to give it a shot (the ease of typical simple Makefile generation, but with extra muscle), but the omission of Tcl as a control/config tool has always baffled me. [0] http://en.wikipedia.org/wiki/CMake#History [1] http://en.wikipedia.org/wiki/Insight_Segmentation_and_Registration_Toolkit edit: formatting
- plorkyeran 13y ago
  s/Some/All/ I hate using autotools, but every time I touch a project that uses something else (and that is too complex for a ten-line Makefile), I inevitably end up wishing that it used autotools. I suppose it shows that sometimes a few decades of polishing a turd does sort of work.
  - krasin 13y ago
    what's about cmake?
    - cleversoap 13y ago
      CMake is interesting because the CMakefiles are just a different type of editable/configurable build script (ie. slightly different Makefiles). It's still an interpreted step between build instructions and the output that you actually use to build which isn't meant to be edited and therefore obfuscates part of the process... so autoconf. This is both a strength and weakness in that there are so many external modules for CMake (eg. the various FindX) that they work great most of the time but when they break they are more difficult to fix than an atomic change to the actual compiler flags in a Makefile. I don't think there will ever be a standard build tool, simply shunts to get the needed functionality from others. Eventually all build tools will exist in each other and the only interface will be recursion.
    - plorkyeran 13y ago
      CMake has the nice property of being able to generate non-Make build systems, but otherwise is more of just "autotools done differently" rather than "autotools done better". In practice I haven't found it to be any more pleasant to use than autotools.
    - CCs 13y ago
      So far CMake served us well. I'm using it for 8 or so years now for small and larger systems. I especially like that one file allows me to develop on XCode, somebody else on Visual Studio and finally deploy on Linux/gcc. One config file creates native projects on all 3 platforms, no manual hacking.
    - 13y ago
- mansr 13y ago
  Most of the so-called modern build tools avoid make entirely, so its syntax cannot be to blame for their miserable quality.
  - deleted 13y ago
    [deleted]
  - brigade 13y ago
    I was thinking more along the lines of if writing for sh and make were less painful, then fewer developers would accept using such awful build systems instead. Autotools included.
    - mansr 13y ago
      I find neither sh nor make particularly painful. Python, however, I cannot stand the sight of.
ChuckMcM 13y ago
I don't know about this. Back in 2003 I got all spun up on scons, and later working at Google and their Build system which was pretty amazing in what it could do. At the same time I discovered that you can't run Windows software, PC hardware, and a Windows OS that are skewed by more than a few years (seriously true for games, less true for productivity apps). And yet I can download thttpd and type 'make' in the directory and it just builds. I've concluded that you can either embrace highly complex evolving systems and build tools which follow that evolution in such a way as to provide functions. Or you can make "point in time" sorts of things that are ephemeral in their ability to do what they do. Not a good choice but the only two that seem to be durable. I completely agree that it is a challenging place to be.

jamesjporter 13y ago

it's interesting how some software problems have garnered many really good solutions while others are still mired in stuff like this. e.g. no matter what your preferred source control tool is I think we can all agree that there are some pretty good options out there these days. compare that to the insanity that prevails in packaging in every corner.

mturmon 13y ago
Text editors are another classic example of this conundrum. Some problems seem to attract problem-solvers, and some do not.
- jjoonathan 13y ago
  I don't follow. We've had TextWrangler, SubEthaEdit, TextMate, Sublime Text, and Smultron alongside rapidly improving IDEs like Coda, XCode, VS, LightTable, and a host of web-based environments like JSfiddle, Cloud9IDE, and Codepen. Text editors don't just attract attention, they attract a lot of attention, and I'm glad for it.
  - mturmon 13y ago
    I have used Emacs and vi since the 1980s, and view this differently. A lot of the work you refer to was largely duplicative. Of course, I'm not talking about IDEs or web-based editors. You're right though, I do enjoy the innovation in web editors.
    - jjoonathan 13y ago
      First of all, drawing a line between IDEs and text editors is a surefire way to ignore the kind of innovation that is happening with regard to text-editing. If you insist on doing this then in your search for innovation you've drawn a box so narrow that you should not be surprised to find nothing in it. There are only so many pure text-editing actions with positive ROI and E&V mastered the bulk of them long ago. Even so, E&V haven't been standing still. It's true they refuse to innovate in certain directions: 1. Out-of-the-box integration with modern toolsets (0-configuration documentation, smart autocomplete, build, debug, jump-to-definition, etc) 2. Present an interface that is easily discoverable by GUI-minded folk 3. Take advantage of the opportunities afforded by non-textual displays but each of these is done "poorly" in E&V for a good reason, as per your text editor / IDE distinction. They can't change these things without stepping on the toes of their power users (i.e. all of them) and leaving behind part of what made them great, which is why this kind of innovation is happening away from E&V. Most of the apps I listed address between 1 and 3 of the above issues. Just because the young upstart editors don't support keyboard input and customization with the fluidity of E&V doesn't mean they are purely derivative. They do something that a lot of people want done that E&V don't do, and they do it well. That's what innovation is all about. So I ask again what it is that you would consider innovation and why the projects I listed don't count.

stefantalpalaru 13y ago

> Joe GNU/Linux User has just downloaded and untared this package. Regular users are not supposed to install software like this. The only sane way to administer a distribution is to make sure everything passes through the official package manager. This leaves the developers and package maintainers to deal with autotools and I don't hear them complaining (very loud[1]). Autotools is simply good enough for the job and instead of being some sort of hated legacy it's being sometimes preferred for new projects (cough [2] cough). [1]: https://blog.flameeyes.eu/tag/autotoolsmythbuster/ https://blog.flameeyes.eu/tag/autotoolsmythbuster/ [2]: https://github.com/stefantalpalaru/vala-skeleton-autotools https://github.com/stefantalpalaru/vala-skeleton-autotools

ahomescu1 13y ago
Not every user has root/sudo access so they can install software system-wide (it's even arguable whether they should, instead of keeping those programs user-local).
Sheepshow 13y ago
Software freedom is the ability to do whatever you want with the code, for example, compiling it. I'm not saying there's any sort of license violation here, but it's not in the spirit of software freedom to "not supposed to install software [from source]"
- stefantalpalaru 13y ago
  Granted, but the freedom to ruin one's system is not a freedom I would promote. Installing software from source is a good thing, you just need to go through the intermediate process of creating a package for your distribution first.
chomp 13y ago
In a perfect world, every single piece of software ever written is in every single distribution's package manager. This is not always the case in reality, however.
- 13y ago

nathell 13y ago

The comment "Put the blame where it belongs: Automake" below the original article sums it up pretty succinctly. Quoting: All the complaints in the article are PRECISELY the kinds of complaints that autoconf programmers worked very hard to avoid. For example, it's IMPOSSIBLE to have version skew with autoconf because the configure script is completely pre-generated before being shipped. As far as the user is concerned it's a simple sh script. ALL of these problems stem from the "automake" monstrosity that creates many more problems than it ever solved. Unfortunately people now tar autoconf with the same brush as automake and libtool whenever they run into problems with these. Sigh.

sehugg 13y ago
I'm seeing some projects shipping without configure which is annoying.
MichaelMoser123 13y ago
For my projects I did a make system that uses gmake meta programming to easily define rules for most cases, here you have to includes a template make file that expands the target definitions into make rules. http://mosermichael.github.io/cstuff/all/projects/2011/06/17/make-system.html http://mosermichael.github.io/cstuff/all/projects/2011/06/17... The catch is of course most cases ; other stuff is still possible to do , but things become hacky. Another downside is cross compilation, my system does not do this effectively (though it works for Linux i686, x86_64 and Cygwin - many surprises between these setups !). Most build systems I know don't support cross compilation - except for automake, the terrible. If you do debian packages then you are strongly encouraged to use automake - because of cross compilation.

caf 13y ago

He again does the typical thing and runs "./configure --prefix=/opt". The configure script runs for a while, then exits with an error which basically translates to "You have an autoconf version which is three weeks old; please upgrade", but this is displayed in the most cryptic manner possible. This is simply incorrect. If you already have a configure script, then you don't need autoconf installed at all, let alone a particular version of it. autoconf is used for generating the configure script, not running it.

ArbitraryLimits 13y ago
I'm positive that I've seen configure scripts that try to check whether they, themselves, are out of date, and regenerate themselves if so. That's the only time I've seen an error about autoconf version skew. To be fair, I've only actually seen this on scripts I was writing - never seen it happen to something that passed make dist.
- plorkyeran 13y ago
  Automake will regenerate and rerun the configure script if configure.ac is newer than configure, which is normally only the case if you're either modifying configure.ac or if the files are packaged incorrectly (and automake makes packaging a release correctly easy).
- kelnos 13y ago
  I don't remember exactly (my autoconf/automake-fu has gotten weak these past years), but there's a macro AM_MAINTAINER_MODE that will add --enable/disable-maintainer-mode as an option to your configure script that will determine if rules get added to the final Makefile that will check to see if Makefile.am is newer than Makefile.in or if Makefile.in is newer than Makefile, or if configure.ac is newer than configure (etc.) and then attempt to regenerate them. I don't quite remember what the default is if you don't include AM_MAINTAINER_MODE in your configure.ac. So yes, you could have indeed seen that happen, but there are ways to make it not happen.

skywhopper 13y ago

Interesting that the alternative tools mentioned in the article (SCons, Cons, and A-A-P), only SCons has been updated since 2003 (according to Freshmeat), and its last update in 2010 appears to have been mainly to redo the version numbers and drop Python 2.4 support.

bjourne 13y ago
https://code.google.com/p/waf/ https://code.google.com/p/waf/ is the spiritual successor to SCons. It started off as a fork of it (due to performance problems in SCons) and then became a full project on its own. It can do everything autotools+make can and you only have to code your build in Python rather than Makefile + M4 + shell scripts. I've been using it for many years and it is technically superior to any build system I've seen. Shame the author of it doesn't market it more -- with some hype it would easily have been the de facto standard build system by now.
- csense 13y ago
  Yeah, scons looked well-designed when I encountered it in 2012 or so, but it also looked dated and unmaintained. Good to know someone's picked up the torch.
- mansr 13y ago
  Replacing make with python is a huge step back. The makefile language is simple yet extremely powerful for describing a dependency tree such as that for building an executable from sources. Its perhaps strongest point is that it completely agnostic to what the different steps actually do rather than consist of a predefined set of canned rules/tasks with, if you're lucky, a convoluted way of adding your own using e.g. python (or worse, java). This means that as long as a shell command can turn a set of inputs into an output, describing it takes (usually) just two lines of makefile, one naming the target and prerequisites, one providing the command to perform the transformation. If a particular rule is too complicated for a few shell commands, invoking a separate script (or even a just-built executable) is trivial. Every other system I've looked at needed a comparatively enormous amount of code for adding even the slightest tweak to the built-in rules. GNU make is actually two different languages coexisting in the same file (the makefile), a declarative language for describing the targets and their dependencies as well as a functional language for the variables/macros. Once you realise this, a whole new world of possibilities opens up. If more people took the time to actually understand proper use of makefiles, perhaps we'd see fewer poorly reinvented wheels.

caitp 13y ago

https://xkcd.com/927/ https://xkcd.com/927/ But on a serious note, I really want to see Gyp become more popular, for the simple reason that integrating multiple Gyp projects is essentially zero-effort. It's a beautiful way of working, even though Gyp certainly has room for improvement.

ahomescu1 13y ago
AFAIK, Gyp's biggest user is Google (Chromium uses it, and maybe others). Are there any non-Google projects that use it?
- caitp 13y ago
  In addition to the big google projects using it (Chromium, V8, WebRTC/jingle, etc), there's also Joyent's Node.js (and forks, + numerous node packages containing native code), as well as numerous private projects that I've been involved with. Unfortunately, it hasn't taken off too much in the open source community apart from the above mentioned big name projects. Better documentation and more visibility could probably make that happen, though.

sparkie 13y ago

We don't need a new build system, we need a new mentality. The problem with build systems is they don't cover the entire scope required to actually build software reliably. Ideally, you want to take just your code as input and produce a target, but the reality is that you're taking your code, plus an environment with potentially infinite number of configuration options, and you're asking the build system to produce a target. This is effectively saying "Here's some code and some shit, please do your wizardry and make me something that looks like this." Is it any wonder that every proposed solution to this difficult (impossible?) problem gets it wrong? The correct solution is to declare the target you want, then build up the dependencies you need as input to meet that target and declare them explicitly, then perform the build in that isolated environment to ensure that no undeclared configuration options can alter the result of the build. This is what Nix (http://nixos.org/nix/ http://nixos.org/nix/) does, and by derivation, Guix (https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/), and Debian's ReproducibleBuilds is also attempting. The build process becomes effectively a pure function, free of unwanted side-effects. Nix doesn't actually perform builds in itself, except for trivial ./configure && make. It piggy-backs on existing build systems via bash scripts if needed, but it completely manages the environment in which such script will run, so it has local-side effects which are controlled, similar to how you might use the ST monad in place of IO in Haskell perhaps. I find Guix a bit more interesting because it can take on the whole problem - including the build system. While it can piggy-back on existing build systems in the same way Nix can, you can also write your own in Guile (or some other language and invoke from Guile). It doesn't really make sense to depend on the old cruft under this new mentality, because things like pkg-config are obsoleted by known, explicitly declared dependencies. The build process can be simplified (and probably sped-up).

_delirium 13y ago
How portable is nix? I haven't looked into it much, but from a (possibly mistaken) first impression it looks more like a replacement for yum or apt than for autotools. Despite being crufty, what I find valuable about autotools is that, given one source directory, I can successfully compile and link the package on many things: various distributions of Linux, the BSDs, Solaris, HP-UX, AIX, OS X, nearly whatever else you care to dream up. Does Nix actually do that (or target it, if not yet)?

J_Darnley 13y ago

Last time I built anything that required one of these autotools monstrosities, which was LAME I might add, it gave me some obscure error about not having a suitable type for a signed 64-bit integer. Which was unbelievably stupid since it had just "found" uint64_t for its unsigned counterpart. So I opened its nearly megabyte sized, thirty-two thousand line long configure file to track down the problem. I seem to recall that in the end I fixed it by correcting the placement of some braces around it many nested ifs to fix it. Now I avoid anything that needs anything like these tools or anything that has a step before running configure from a source code checkout.

dventimi 13y ago

Running "./configure && make && make install" usually results in a working installation of whatever package you are attempting to compile. followed by the auto tools are constantly a thorn in the side of users and developers alike. Which is it? Do the autotools "usually [result] in a working installation" or are they "constantly a thorn in [our sides]?"

mateuszf 13y ago
Usually in that case is not enough. Developer is potentially dealing with big number of users. Even a small percentage of people having problems with build is being a very suboptimal situation.

mschuster91 13y ago

I don't have many problems with the auto* toolkit. Yet, there is one problem which has cost me lots of money for buying beer and getting myself filled up: why can't auto* check for all libraries and then output an aggregated "libx,liby and libz missing, libfoo outdated" instead of the configure - apt-get - configure - apt-get cycle?

andrewflnr 13y ago
Because it's just a bunch of macros. To create an aggregated list, they would all have to, instead of printing out what they want, add their info to some global variable, whose name they all agree on in advance and probably with some kind of standard format. Which isn't to say it couldn't be done, but it would be much more complicated.
- mansr 13y ago
  It wouldn't take much at all to have the AC_ERROR macro append the message to a global variable, set a global error flag, and continue. At the end of the script, if the error flag is set, the aggregated error messages would be printed. The variable names would only need to be coordinated between AC_ERROR and one other macro called at the end.

oakwhiz 13y ago

I'm surprised there has not been any mention of Gitian, the build system used by Bitcoin to perform exactly deterministic builds. The purpose of this is to enable multiple developers to prove that they are all signing the same binary. http://gitian.org/ http://gitian.org/

dror 13y ago

That's an old school build approach (it was 2003). The modern approach is: apt-get install (or your OS equivalent). It's 2014. I can't remember the last time I needed to install a package from source. Worst case scenario I need to add a repo.

deleted 13y ago

[deleted]

fsloth 13y ago

As build systems go, this seems like a promising experiment: http://sourceforge.net/p/meson/wiki/Design%20rationale/ http://sourceforge.net/p/meson/wiki/Design%20rationale/ tl/dr: -DSL for builds with well defined semantics, leverages existing toolchain -design constraints for the system that make sense, i.e. speed, portability, usability and common sense -does not try to reinvent the wheel but rather simplify the usage of existing tools - the build config it generates on my Ubuntu box seems to really deliver on the speed promise - I have no benchmarks to quote but a small c++ codebase using all sorts of dependencies including boost compiled nearly instantly

dschiptsov 13y ago

There is nothing wrong with autoconf or libtool. Take a look how sane developers (nginx, cpython, etc) are using it.