I know you're going to say I should be using the VCS checkout in the first place, which would hopefully be configured to ignore the autogenerated files. WTF IS ALL THIS MESS IN THE DIFF I NEVER TOUCHED?!!?! $ diff -urN autotools-using-package.orig autotools-using-package $ mv temp/autotools-using-package autotools-using-package.orig
Install: no such file or directory blabla.la
No damn, I wanted to generate configure, not run it! How do I clean up the mess it made just now? How do I get the old one but keep the new one around? Spend another 30 minutes to figure that out.
Autogen.sh cmake command not found install#
Oh, I need to install an old version of auto*! Įrror: possibly undefined macro AC_BLABLABA Trying to change the CMake source files for someone unfamiliar with its "language" and variable name conventions is annoying and error-prone.Ĭonfigure, compile, install. 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.
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. Many POSIX-compatible libraries using autotools/libtool can be compiled on OS X without changes, and often MingW too. Most porting pain comes from bad package management. 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.Įven on Windows, it works fairly well with MingW. Are you kidding? Porting tools to other platforms is the main selling point of autotools.
0 kommentar(er)
