[OT] Thank you for not using autoconf

Mike Frysinger vapier at gentoo.org
Sat Jun 1 03:01:18 UTC 2013


On Friday 31 May 2013 20:36:16 Laurent Bercot wrote:
> On Fri, May 31, 2013 at 02:46:51PM -0400, Mike Frysinger wrote:
> > autotools tends to work a lot more reliably than
> > $random-build-system-of-the-day.
> 
>  That's a testimony to the suckiness of $random-build-system-of-the-day,
> not a proof that autotools work well. They don't. They probably suck
> less than most of the things you see, but they still suck.

they suck the least of everything i've seen.  i'm not talking about just hand 
written build systems.

hell, cmake still can't properly cross-compile things today, and scons forces 
you to basically open code support in every project.  python is completely 
buggered, as is perl.  off the top of my head, that covers the major players in 
the alternative build system space.

>  One simple example: I could *never* make autotools understand that I
> wanted to compile natively for i386, *but* wanted to use the diet libc
> instead of the glibc. Never. To make it work, I had to use horrible hacks
> that would make your ears bleed. I'm still ashamed of those today.

if you properly configured your toolchain, this isn't an issue.  if you're 
doing hacky stuff like using the host gcc that was built for glibc but trying 
to get it to use a dietlibc you've compiled & installed in a random path, 
you're going to see pain.  but you *should* see pain.

when you build gcc, you configure it for a specific target.  it changes its 
behavior based on the C library it was built against.  trying to use that gcc 
with a completely different C library is only going to go down in flames for 
everything other than basic "hello world" apps.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20130531/94644879/attachment.asc>


More information about the busybox mailing list