4 ms·
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
by 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 agoyes! 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 agoI 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 agoI 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.