5 ms·

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

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.

cperciva 11y ago
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?
- makomk 11y ago
  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.
  - cperciva 11y ago
    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.
    - mzs 11y ago
      Sadly I think you still need -lnsl -lsocket on solaris :(
      - cperciva 11y ago
        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.
        mzs 11y ago
        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.
        cperciva 11y ago
        You don't even need autotools for those simple things though.
        lmm 11y ago
        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.

cperciva 11y ago

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?

makomk 11y ago
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.
- cperciva 11y ago
  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.
  - mzs 11y ago
    Sadly I think you still need -lnsl -lsocket on solaris :(
    - cperciva 11y ago
      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.
      - mzs 11y ago
        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.
        cperciva 11y ago
        You don't even need autotools for those simple things though.
        lmm 11y ago
        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.