5 ms·

this deliberately ignores the new features we've gotten in the meantime. gcc is slow when you turn on all the optimizations. when computers were run by SysOps

this deliberately ignores the new features we've gotten in the meantime. gcc is slow when you turn on all the optimizations. when computers were run by SysOps and every program needed to be recompiled from scratch for each slightly-different machine, it wasn't worth making the compiler ten times slower to make the program five percent faster. today, when browsers are compiled once and then run by millions of users for billions of hours a day, the tradeoff is different. sure, autoconf is bad, particularly today when it's used completely wrong, but is it really worse than when programs had to be completely manually ported between different Unix versions, in a day when "package manager" had yet to be a twinkle in anybody's eye? is everything great now? no, of course not. but you're grasping at the completely wrong straws here.

buserror 7y ago
It's still slow on -O0, it's slow because it doesn't approach the problem of compiling a complete program the right way, like these old compilers did. The fact that everything is a file, the fact that every single header needs to /searched for/ then /compiled/ millions of times, and optimized later on, without context; that is the problem. I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go. Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways. More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up? Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.
- icedchai 7y ago
  yes! Even in the 90's you could take care of the common cases with a few different flags. I had C apps that built on various Linux distros, FreeBSD, Digital Unix, SunOS 4.x, and Solaris with hardly any changes other than a couple ifdefs. Sure, if you compile your program on a Sequent running DYNIX, circa 1988, you might hit a few snags.
- bregma 7y ago
  I build embedded software for profit only and I can say with certainty the 98% of all computers out there are not desktops and do not use desktop operating systems. For those systems, the autotools, modern optimizing compilers, and modern tooling like distributed ccache are a godsend. Of course, back in the 1990s similar software was fast to build because your cross-assembler didn't have to worry about on-chip cache or superscalar architectures, but ye gods the code PTSD flashbacks begin.
- rjsw 7y ago
  I run NetBSD on my Mac Quadra 950 as well as MacOS. I usually give up trying to run autoconf on it after a few days.
pjmlp 7y ago
Compared with Visual C++ it is definitely slow.

buserror 7y ago

It's still slow on -O0, it's slow because it doesn't approach the problem of compiling a complete program the right way, like these old compilers did. The fact that everything is a file, the fact that every single header needs to /searched for/ then /compiled/ millions of times, and optimized later on, without context; that is the problem. I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go. Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways. More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up? Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.

icedchai 7y ago
yes! Even in the 90's you could take care of the common cases with a few different flags. I had C apps that built on various Linux distros, FreeBSD, Digital Unix, SunOS 4.x, and Solaris with hardly any changes other than a couple ifdefs. Sure, if you compile your program on a Sequent running DYNIX, circa 1988, you might hit a few snags.
bregma 7y ago
I build embedded software for profit only and I can say with certainty the 98% of all computers out there are not desktops and do not use desktop operating systems. For those systems, the autotools, modern optimizing compilers, and modern tooling like distributed ccache are a godsend. Of course, back in the 1990s similar software was fast to build because your cross-assembler didn't have to worry about on-chip cache or superscalar architectures, but ye gods the code PTSD flashbacks begin.
rjsw 7y ago
I run NetBSD on my Mac Quadra 950 as well as MacOS. I usually give up trying to run autoconf on it after a few days.

pjmlp 7y ago

Compared with Visual C++ it is definitely slow.