|
|
|
|
|
|
by ambrop7
4959 days ago
|
|
|
$ tar xf autotools-using-package.tar.bz2
$ cd autotools-using-package
Configure, compile, install. Oh, I found this little bug. Let's try to fix it ... edits configure.ac .... $ ./autogen.sh
Error: possibly undefined macro AC_BLABLABA
Spend some hours figuring this out... Oh, I need to install an old version of auto*!
How do I get the old one but keep the new one around? Spend another 30 minutes to figure that out. $ ./autogen.sh
checking for build system type...
^C
No damn, I wanted to generate configure, not run it! How do I clean up the mess it made just now? $ make clean
$ make distclean
$ ./configure --prefix=$HOME/my_app ...
$ make -j9 install
...
install: no such file or directory blabla.la
WTF!?!?!
Spend an hour or so googling this mess. Ah, it's a parallel-make bug. $ make install
HOLY SHIT, IT INSTALLED!!!Let's submit this fix upstream. No problem, use diff. $ mkdir temp
$ tar xf autotools-using-package.tar.bz2 -C temp
$ mv temp/autotools-using-package autotools-using-package.orig
$ diff -urN autotools-using-package.orig autotools-using-package
WTF IS ALL THIS MESS IN THE DIFF I NEVER TOUCHED?!!??!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. But as a user, or distribution maintainer, most of the time the bug you find is with a specific, packaged version of the software, and it may be quite an effort to figure out how to get the exact same version from the VCS server. |
|
|
I always run "./autogen.sh --help" for exactly that reason; then if I see --help output from configure, I know that autogen.sh "helpfully" ran configure for me.
You can also usually just run "autoreconf -v -f -i" directly, unless the package has done something unusual that it needs to take extra steps in autogen for.