Hacker News Reader

Comment by cperciva | Hacker News Reader

Just in case you're serious: Not using autotools is a feature, not a bug.

Could not agree more. I hope somebody write a sane toolchain for open source once.

man, I hope he's not serious

For a library that wants to be ubiquitous (and therefore wants to be cross-platform) it's a bug. Can I expect this to build cleanly on GNU/kFreeBSD, or windows SUA? If it were autotools I would.

Standards-compliant C is more portable than autotools. Autotools is a workaround for non-portable code.

That's a nice ideal, but reality is that it's really easy to need POSIX APIs and then you're firmly in autotools land. That said, I don't like autotools because it encourages #ifdef style nonsense, but not using it requires a lot more thought and more than a little rolling-your-own code and techniques.

reality is that it's really easy to need POSIX APIs

Sure.

and then you're firmly in autotools land

Not at all. If you need the send(2) POSIX system call, what are you going to do if autotools detects that you're on a platform which doesn't have the send(2) system call?

If you're on a platform that doesn't have send(2), you most likely don't have TCP/IP support either and there's no point trying to run an internet server on it. However it is often stuffed away in an oddball platform-specific header and library, and that's where autotools come in - they detect the appropriate flavour of #include statement and the correct library to use.

No - send(2) was often stuffed away in oddball places, and that's why autotools was important 20 years ago; but it isn't any more.

Sadly I think you still need -lnsl -lsocket on solaris :(

Touché! (I think only -lsocket is required for send(2) though -- unless I'm misremembering, -lnsl is just for DNS lookups.)

Still, there's relatively few portability issues these days:

1. Some platforms don't define MSG_NOSIGNAL. (You can work around this via setsockopt.)

2. Some platforms don't define CLOCK_REALTIME. (On platforms which don't provide that, you should be able to use gettimeofday.)

3. Some platforms don't understand -lrt or -lxnet. (This one is awkward since some platforms require those. You have to either taste the compiler or detect the OS.)

4. Solaris needs -lsocket and/or -lnsl for networking related functions. (Either detect Solaris or decide that it's rare enough that you don't really care about supporting it. In spiped I opt for a note in BUILDING telling people how to work around the Solaris standards-compliance bug.)

Compare this to the situation when autotools originated, and we're about 99% better.

Autotools for these pretty simple things is an okay approach, but then people tend to go overboard, and that's when it gets horrible (or autoconf itself breaks libxnet detection cause it gets some quoting or who knows what wrong in some release). My personal pet peeve is people detecting endian in obtuse ways that totally fails during cross-compiling when there's the perfectly fine ntoh family.

You don't even need autotools for those simple things though.

You don't need autotools, but autotools is the consistent way to do it; the "installed base" is large enough that any sysadmin knows how to deal with autotools (and will have to for many years). Writing your own custom check, even if that check is much more concise in and of itself, makes it harder for a sysadmin to understand your project build than just doing the same thing as every other project.

Reply on news.ycombinator.com