Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux)

Bill> This brings up a question I have always had about the XEmacs autoconf Bill> support. Why is it that you cannot simply do `autoreconf'. Touching Bill> config.h.in by hand is gross. I completely thrashed a XEmacs source tree Bill> once when I did an autoreconf - the config.h.in it produced was unusable. I've never used autoreconf. It's supposed to be a front-end to autoconf + autoheader - but we don't use autoheader. We hand-maintain our own config.h.in. Bill> Also, if you do it in the current tree I get the oh-so-helpful error from Bill> autoreconf. :) Bill> /usr/bin/autoreconf: test: src/config.h: binary operator expected Bill> How close are we to being able to lose Makefile.in.in completely? Only a few light years. A project worth investigating is trying to migrate to automake directly. But I'm not sure offhand what it would buy us. Maybe we would get libtool shared lib support for free? Now that would be worth something. Martin