Hacker News new | past | comments | ask | show | jobs | submit login

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.


So what does work on OpenVMS?


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.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: