12 ms·

It's a very nice read with many good points, but any person with some experience in IT projects could argue with it. The author is taking one side without any s

by haddr 10y ago

It's a very nice read with many good points, but any person with some experience in IT projects could argue with it. The author is taking one side without any self-criticism. It is true that configure scripts are probably doing some useless things, "31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code", etc. But then what is the alternative? Writing a configure module each time by every programmer who wants to release some software? This is called code reuse and yes, it's not perfect but it saves time. By not reinventing the wheel again and again. By reusing something that is stable and has been there for some time. Probably such thing is generalizing over many architectures, and making useless things, but then again, who cares for some extra 5-10 seconds of the "configure" command, when you are covered for all those strange corner cases that it already handles?

x0x0 10y ago
Insane complexity in build systems just makes your life sad. Trust me, I know -- I write java for a living. We have ivy, maven, ant, gradle, sbt, leiningen, and I'm sure a few more.
- d_burfoot 10y ago
  Hey, I write Java for a living and my build script is just a Python program that marshals a javac call.
  - qwertyuiop924 10y ago
    I write scheme not for a living. My build script is a scheme file or a makefile, depending on the project. The build complexity is one of the reasons I stay away from Java: If these people think they need XML for builds, what other needlessly complex horrors have they perpetrated? And that sort of thing. Do you have your buildscript template on github?
    - quantumhobbit 10y ago
      I'm beginning to think that build scripts should be written in the language they are building, or a more expressive language. So many seem to go in the other direction.
      - flukus 10y ago
        I disagree. The worst problems I see with build scripts are that they are trying to do too much, create branches/tags of themselves, be environmentally aware, etc. Limited build tools are a good thing.
        quantumhobbit 10y ago
        I really do agree that complexity is the enemy, but people keep shoving complexity into build scripts against better judgment. I've given up and would rather deal with a complex ruby script than a makefile of equal intrinsic complexity.
      - ashitlerferad 10y ago
        I disagree. We need declarative build systems instead so building is auditable and doesn't require arbitrary code execution.
        profquail 10y ago
        Something like plmake then? (plmake is a build system written in prolog) https://github.com/cmungall/plmake https://github.com/cmungall/plmake
        ashitlerferad 10y ago
        plmake allows arbitrary code execution during the build.
        Annatar 10y ago
        No we don't! GNU Make is exactly what we need; that's pah-lenty declarative in the right hands. All you have to do now is make sure your hands are the right hands. Like buddha said: right mind.
- lmm 10y ago
  I write Scala for a living. Once you embrace the straightjacket of maven you never have to worry about your build again. You write a simple declarative definition, where you just list your project's name/version/etc. and your dependencies. Then you build it. When you want to do something e.g. releasing, you find the standard plugin for doing that and you do with it, and you deal with its defaults. When you decide you absolutely have to pass different compiler arguments depending on the phase of the moon, slap yourself until it passes. When you actually want to write a "reasonable" custom build step that makes sense, writing it as a plugin is not hard and makes it much easier to use good practices.
mjevans 10y ago
Mostly, he's lamenting the need for it. The fact that after 3 decades this thing that every modern OS needs isn't a standard. It actually is kind of silly that you can't depend on this stuff being abstracted, but instead must individually test it instead of asking a reference on a given system.
- thwarted 10y ago
  And yet when it comes to browser compatibility, it's encouraged, nigh necessary, to test for capabilities rather than check version strings and assume that the version string is saying something meaningful about the environment. "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36", indeed.
technofiend 10y ago
I'm not sure why you wouldn't pack the config chains like a fractal of dependencies and only probe (for instance) for Fortran if it's required.
- endgame 10y ago
  Didn't libtool 2.0's autoconf macros do away with the need to check for CXX and F77 on totally irrelevant projects?
xapata 10y ago
> writing a configure module each time No, he suggested writing the code to be cross-platform so that configuration at compile time is unnecessary.
phkamp 10y ago
The alternative ? You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>. Then you could eliminate all the other autocrap checks which come out one and the same way on every single OS in existence. And in all likelyhood, you would find out that you don't actually need autocrap at all, because the remaining two checks can be done with an #ifdef instead.
- Annatar 10y ago
  Yes, why can't we have Makefile.template Makefile.SunOS Makefile.Linux Makefile.FreeBSD and then if a new port is desired, just cp Makefile.template Makefile.'uname' && vi Makefile.'uname' UNIX: keeping it simple since 1970.
  - lmm 10y ago
    I built a fair bit of OSS on SUA back when that existed. Autoconf projects were wonderful: download the tarball, if the tarball is older than the OS I'm building on then replace config.sub, ./configure, make, make install. All standard, all scriptable; never once had a problem with a project that used autotools (or, in fairness, CMake or SCons - all the big reasonably standardized build systems work). People who'd "kept it simple" like you suggest were the bane of my life. I spent more time debugging each of those builds than all of the builds that used actual tools combined. (Ironically enough "all projects must use autotools" seems like a quite cathedrally attitude though)
    - pjmlp 10y ago
      Yeah, nowadays I just embrace OS agnostic languages with rich runtimes and don't care about those things anymore. There are of course occasional glitches, but not like those ones.
      - Annatar 10y ago
        Last I heard Microsoft Windows was obsolete something like ten years ago, is there an operating system other than UNIX left out there, that your application would have to be agnostic?
adekok 10y ago
> who cares for some extra 5-10 seconds of the "configure" command For me, it's closer to a minute. "configure" is good enough that it does the job, and it's hard to replace it. "configure" is bad enough that I loathe it with emotions that words cannot describe. It's design is terrible. It's slow. It's opaque and hard to understand. It doesn't understand recursion (module code? pshaw!) automake is similarly terrible I looked at it 20 years ago, and realized that you could do 110% of what automake does with a simple GNU Makefile. So... that's what I've done. I used to use libtool and libltdl in FreeRADIUS. They gradually became more pain than they were worth. libtool is slow and disgusting. Pass "/foo/bar/libbaz.a", and it sometimes magically turns that to "-L/foo/bar -lbaz". Pass "-lbaz", and it sometimes magically turns it into linking against "/foo/bar/libbaz.a". No, libtool. I know what I'm doing. It shouldn't mangle my build rules! Couple that with the sheer idiocy of a tool to build C programs which is written in shell script. Really? You couldn't have "configure" assemble "libtool.c" from templates? It would only be 10x faster. And libltld was just retarded. Depressingly retarded. I took the effort a few years ago to replace them both. I picked up jlibtool and fixed it. I dumped libltld for just dlopen(). The build for 100K LoC and ~200 files is about 1/4 the time, and most of that is running "configure". Subsequent partial builds are ~2s. If I every get enough time, I'll replace "configure", too. Many of it's checks are simply unnecessary in 2016. Many of the rest can be templated with simple scripts and GNU makefile rules. Once that's done, I expect the build to be ~15s start to finish. The whole debacle around configure / libtool / libltdl shows that terrible software practices aren't new. The whole NPM / left-pad issue is just "configure" writ large.
- mcguire 10y ago
  Actually, the configure debacle doesn't have anything to do with terrible software practices. All of Sun, AT&T, HP, SGI, IBM, DEC, the BSD guys, the semi-embedded guys, and every else had the best architects they could get. They were (and are) brilliant and did brilliant things. Kemp is one of them, for example. Heck, you can complain about Microsoft and Apple, but you cannot say they're incompetent. Unfortunately, there are two problems. 1. They were all operating under different requirements. 2. They were all absolutely convinced that they were the best in the business and that they were right. As a direct result, those of us who got to deal with more than one of the resulting systems want to beat them all to death with a baseball bat with nails driven into the end.
wruza 10y ago
>who cares for some extra 5-10 seconds of the "configure" command Building freebsd-7 ports on my athlon felt like "forever and 2 more days" back then. If it is not possible to remove autoconf/configure with all obsolete options, can we at least PLEASE stop doing the same thing again and again 220 times for each small package in enormous dependency list? Caching, anyone?

by haddr 10y ago

x0x0 10y ago

Insane complexity in build systems just makes your life sad. Trust me, I know -- I write java for a living. We have ivy, maven, ant, gradle, sbt, leiningen, and I'm sure a few more.

d_burfoot 10y ago
Hey, I write Java for a living and my build script is just a Python program that marshals a javac call.
- qwertyuiop924 10y ago
  I write scheme not for a living. My build script is a scheme file or a makefile, depending on the project. The build complexity is one of the reasons I stay away from Java: If these people think they need XML for builds, what other needlessly complex horrors have they perpetrated? And that sort of thing. Do you have your buildscript template on github?
  - quantumhobbit 10y ago
    I'm beginning to think that build scripts should be written in the language they are building, or a more expressive language. So many seem to go in the other direction.
    - flukus 10y ago
      I disagree. The worst problems I see with build scripts are that they are trying to do too much, create branches/tags of themselves, be environmentally aware, etc. Limited build tools are a good thing.
      - quantumhobbit 10y ago
        I really do agree that complexity is the enemy, but people keep shoving complexity into build scripts against better judgment. I've given up and would rather deal with a complex ruby script than a makefile of equal intrinsic complexity.
    - ashitlerferad 10y ago
      I disagree. We need declarative build systems instead so building is auditable and doesn't require arbitrary code execution.
      - profquail 10y ago
        Something like plmake then? (plmake is a build system written in prolog) https://github.com/cmungall/plmake https://github.com/cmungall/plmake
        ashitlerferad 10y ago
        plmake allows arbitrary code execution during the build.
      - Annatar 10y ago
        No we don't! GNU Make is exactly what we need; that's pah-lenty declarative in the right hands. All you have to do now is make sure your hands are the right hands. Like buddha said: right mind.
lmm 10y ago
I write Scala for a living. Once you embrace the straightjacket of maven you never have to worry about your build again. You write a simple declarative definition, where you just list your project's name/version/etc. and your dependencies. Then you build it. When you want to do something e.g. releasing, you find the standard plugin for doing that and you do with it, and you deal with its defaults. When you decide you absolutely have to pass different compiler arguments depending on the phase of the moon, slap yourself until it passes. When you actually want to write a "reasonable" custom build step that makes sense, writing it as a plugin is not hard and makes it much easier to use good practices.

mjevans 10y ago

Mostly, he's lamenting the need for it. The fact that after 3 decades this thing that every modern OS needs isn't a standard. It actually is kind of silly that you can't depend on this stuff being abstracted, but instead must individually test it instead of asking a reference on a given system.

thwarted 10y ago
And yet when it comes to browser compatibility, it's encouraged, nigh necessary, to test for capabilities rather than check version strings and assume that the version string is saying something meaningful about the environment. "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36", indeed.

technofiend 10y ago

I'm not sure why you wouldn't pack the config chains like a fractal of dependencies and only probe (for instance) for Fortran if it's required.

endgame 10y ago
Didn't libtool 2.0's autoconf macros do away with the need to check for CXX and F77 on totally irrelevant projects?

xapata 10y ago

> writing a configure module each time No, he suggested writing the code to be cross-platform so that configuration at compile time is unnecessary.

phkamp 10y ago

The alternative ? You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>. Then you could eliminate all the other autocrap checks which come out one and the same way on every single OS in existence. And in all likelyhood, you would find out that you don't actually need autocrap at all, because the remaining two checks can be done with an #ifdef instead.

Annatar 10y ago
Yes, why can't we have Makefile.template Makefile.SunOS Makefile.Linux Makefile.FreeBSD and then if a new port is desired, just cp Makefile.template Makefile.'uname' && vi Makefile.'uname' UNIX: keeping it simple since 1970.
- lmm 10y ago
  I built a fair bit of OSS on SUA back when that existed. Autoconf projects were wonderful: download the tarball, if the tarball is older than the OS I'm building on then replace config.sub, ./configure, make, make install. All standard, all scriptable; never once had a problem with a project that used autotools (or, in fairness, CMake or SCons - all the big reasonably standardized build systems work). People who'd "kept it simple" like you suggest were the bane of my life. I spent more time debugging each of those builds than all of the builds that used actual tools combined. (Ironically enough "all projects must use autotools" seems like a quite cathedrally attitude though)
  - pjmlp 10y ago
    Yeah, nowadays I just embrace OS agnostic languages with rich runtimes and don't care about those things anymore. There are of course occasional glitches, but not like those ones.
    - Annatar 10y ago
      Last I heard Microsoft Windows was obsolete something like ten years ago, is there an operating system other than UNIX left out there, that your application would have to be agnostic?

adekok 10y ago

> who cares for some extra 5-10 seconds of the "configure" command For me, it's closer to a minute. "configure" is good enough that it does the job, and it's hard to replace it. "configure" is bad enough that I loathe it with emotions that words cannot describe. It's design is terrible. It's slow. It's opaque and hard to understand. It doesn't understand recursion (module code? pshaw!) automake is similarly terrible I looked at it 20 years ago, and realized that you could do 110% of what automake does with a simple GNU Makefile. So... that's what I've done. I used to use libtool and libltdl in FreeRADIUS. They gradually became more pain than they were worth. libtool is slow and disgusting. Pass "/foo/bar/libbaz.a", and it sometimes magically turns that to "-L/foo/bar -lbaz". Pass "-lbaz", and it sometimes magically turns it into linking against "/foo/bar/libbaz.a". No, libtool. I know what I'm doing. It shouldn't mangle my build rules! Couple that with the sheer idiocy of a tool to build C programs which is written in shell script. Really? You couldn't have "configure" assemble "libtool.c" from templates? It would only be 10x faster. And libltld was just retarded. Depressingly retarded. I took the effort a few years ago to replace them both. I picked up jlibtool and fixed it. I dumped libltld for just dlopen(). The build for 100K LoC and ~200 files is about 1/4 the time, and most of that is running "configure". Subsequent partial builds are ~2s. If I every get enough time, I'll replace "configure", too. Many of it's checks are simply unnecessary in 2016. Many of the rest can be templated with simple scripts and GNU makefile rules. Once that's done, I expect the build to be ~15s start to finish. The whole debacle around configure / libtool / libltdl shows that terrible software practices aren't new. The whole NPM / left-pad issue is just "configure" writ large.

mcguire 10y ago
Actually, the configure debacle doesn't have anything to do with terrible software practices. All of Sun, AT&T, HP, SGI, IBM, DEC, the BSD guys, the semi-embedded guys, and every else had the best architects they could get. They were (and are) brilliant and did brilliant things. Kemp is one of them, for example. Heck, you can complain about Microsoft and Apple, but you cannot say they're incompetent. Unfortunately, there are two problems. 1. They were all operating under different requirements. 2. They were all absolutely convinced that they were the best in the business and that they were right. As a direct result, those of us who got to deal with more than one of the resulting systems want to beat them all to death with a baseball bat with nails driven into the end.

wruza 10y ago

>who cares for some extra 5-10 seconds of the "configure" command Building freebsd-7 ports on my athlon felt like "forever and 2 more days" back then. If it is not possible to remove autoconf/configure with all obsolete options, can we at least PLEASE stop doing the same thing again and again 220 times for each small package in enormous dependency list? Caching, anyone?