Have you ever tried to port a package that is using autotools to a platform that is not based on GNU/Linux?
Among those of us that have attempted or have done that port, most will probably not look particularly favorably on autotools again.
One of the easiest approaches here involves reverse-engineering the autotools product from a test run performed on a GNU/Linux box, and then translating and building a platform-specific script.
From what I can tell of it, autotools makes substantial use of GNU/Linux features. Which is certainly fine for its intended platform and typical usage, but it's an approach that is Not Fun for porting that code.
Are you kidding? Porting tools to other platforms is the main selling point of autotools. Why do you think it goes to such pains to avoid bash-isms in its output, sticking to raw POSIX shell code, even to the point of avoiding functions and loops? This is specifically to support weird esoteric * -nixes.
Even on Windows, it works fairly well with MingW. Most porting pain comes from bad package management.
Many POSIX-compatible libraries using autotools/libtool can be compiled on OS X without changes, and often MingW too. That isn't true for many other systems.
More importantly, when you do need to make a change, it's a simple edit of shell code and some pretty straight-forward makefile variables. It could just be unfamiliarity, but I've tried customizing the output of CMake for some specific situations and the complexity of the its makefiles is pretty prohibitive. Trying to change the CMake source files for someone unfamiliar with its "language" and variable name conventions is annoying and error-prone.
Autotools will go to great lengths to check if I'm running BSD 4.2, or a specific version of Xenix from 1987, but just you try running it if your "ls" doesn't have a -i flag! Apparently, a filesystem not based around inodes is just inconceivable.
Kidding? No. I'm not. To my point, try porting an autotools package to OpenVMS, for instance. No autotools. Weak bash. No CMake, either. And trying to port autotools itself has been an on-going project; that's been no small effort and attempted by a number of folks, and (so far) no particular success.
gmake scripts are usually fairly portable to OpenVMS, and there is a decent — though not great — ability to invoke bash build scripts directly.
If I had my druthers here, I'd like a build tool that wasn't a layer atop GNU/Linux/Unix — and that's not to imply how autotools works here is at all bad or particularly wrong, it's just an approach that's a bear to port the tools — and have that (portable) build tool then generate the platform-specific build script, build procedure, build-whatever equivalent.
Conceptually: to move the existing builds from a procedural, interpreted approach into a higher-level and object-oriented approach.
> Have you ever tried to port a package that is using autotools to a platform that is not based on GNU/Linux?
I think you mean Unix, not GNU/Linux. Porting from one flavor of Unix to another is the raison d'etre of autoconf. It's really quite valuable when you're the one in charge of babysitting 20-year-old AIX or HPUX boxes.
It's not even meaningful to talk about using the autotools on a non-Unix platform, since autoconf emits shell scripts. It sounds like you've run into problems with automake on a non-Unix platform generating Makefiles with shell code in it?
The thing is, 20 years ago maybe you developed on a Sun box, then the guy down the hall tried to compile it on his HP machine and it crapped itself because of some Sun-related assumption you made in setting things up. Then you mail it to a colleague across the state and he compiles it on OSF/1, hurrah!
But now, people write Linux libraries, tested on a Linux box, for people running Linux, and only compiled on Linux. There may be OS X support. That's it. This is not the 1980s, where 10,000 Unixes bloomed. With 4 Makefiles, you could support Linux, OS X, Windows, and FreeBSD, and thus cover 99% of your audience. I'm sick of watching configure scripts take longer to run than the actual compilation.
Except that before "just supporting Linux (and maybe MacOS)" was the thing to do, it was "just support Sun (and maybe HP-UX)". And before that, it was "just support BSD/Vax (and maybe SVR2)".
So, when you take a broader view than "just support what everyone uses", you're not just helping niche platforms -- you're future-proofing.
Among those of us that have attempted or have done that port, most will probably not look particularly favorably on autotools again.
One of the easiest approaches here involves reverse-engineering the autotools product from a test run performed on a GNU/Linux box, and then translating and building a platform-specific script.
From what I can tell of it, autotools makes substantial use of GNU/Linux features. Which is certainly fine for its intended platform and typical usage, but it's an approach that is Not Fun for porting that code.