Well, the adventure with automake continues. I'm starting to get a good feel for things. Reading the automake manual requires you to pay attention, but most of the information I need is there. One thing I've come to question is whether or not we care to retain the separate send-pr directory. It appears that send-pr was intended to operate with or without the presence of pr-edit and query-pr, falling back to sendmail. It could be distributed to your customer/client as a generic shell script with no external dependencies. Currently, I've retained and updated the configure.ac file in send-pr, added Makefile.am and dumped Makefile.in (built by automake). We *could* distribute send-pr independent of GNATS, but *should* we? (This isn't rhetorical. I would really like to know your opinions.) Over the years, it appears that the send-pr.texi manual has been fully integrated into the GNATS manual. Additionally, the emacs *.el file has been dropped in favor of the gnats.el file. By all indications, send-pr doesn't appear to exist separately from GNATS at all. If one wishes to distribute send-pr to a customer, she could tarball up send-pr, send-pr.1, install-sid, and install-sid.8. Even that is not highly necessary. The functionality of install-sid (updating a config file) could be rolled into send-pr. Hmm... I just did a search against help-gnats for send-pr to see if this conversation had popped up in the past and found an interesting post. [1]_ It appears that Yngve had created a manpage for send-pr.conf back in 2001 that doesn't appear to exist in our CVS repository. We should probably roll that in, updated for today's use. ;-) So, what do you folks say? Roll send-pr into GNATS proper and dump the extra build infrastructure or keep it pseudo-separate? .. [1] http://lists.gnu.org/archive/html/help-gnats/2001-05/msg00040.html -- Chad Walstrom http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */