4 ms·

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

by cperciva 11y ago

feld 11y ago
man, I hope he's not serious
istvan__ 11y ago
Could not agree more. I hope somebody write a sane toolchain for open source once.
lmm 11y ago
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.
- cperciva 11y ago
  Standards-compliant C is more portable than autotools. Autotools is a workaround for non-portable code.
  - __david__ 11y ago
    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.

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

feld 11y ago

man, I hope he's not serious

istvan__ 11y ago

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

lmm 11y ago

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.

cperciva 11y ago
Standards-compliant C is more portable than autotools. Autotools is a workaround for non-portable code.
- __david__ 11y ago
  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.