JJ> I am working on adding ViaVoice support to XEmacs as a module. I need JJ> to find the ViaVoice libraries, with configure. How should this be JJ> handled? Should I have a configure script in the module directory? If JJ> so, will the include of config.h via emodules.h still pick up the right JJ> config.h? Or should I ask to have the main configure script add JJ> ViaVoice detection once the module is ready? JJ> If this question is answered somewhere already, a pointer is sufficient. If it's a simple addition like AC_CHECK_LIB, the simplest is just to add a test to configure.in, even though XEmacs proper won't use it. The proper architected solution is for the module to have its own configure script, and write its output to a file with a different name from config.h, so that you don't get name conflicts. But trust me, you don't want to get into the business of maintaining a configure tool set if you can avoid it.

SY> * "Jerry" == Jerry James <james(a)eecs.ukans.edu&gt; writes: Jerry> I am working on adding ViaVoice support to XEmacs as a module. I need Jerry> to find the ViaVoice libraries, with configure. How should this be Jerry> handled? Should I have a configure script in the module directory? If Jerry> so, will the include of config.h via emodules.h still pick up the right Jerry> config.h? Or should I ask to have the main configure script add Jerry> ViaVoice detection once the module is ready? SY> Does it even need to be in the core distribution at all? I don't mean SY> that I don't think XEmacs needs ViaVoice support. What I'm saying is, SY> why can't you package your ViaVoice module separately from the core, SY> with its own configure/build process? That is the "architecturally correct" way to do it. But in practice it's probably reasonable to add a hack to our configure.in so that an external package doesn't have to maintain one.

WMP> For actual OS things that they would need to check for that XEmacs' WMP> config.h doesn't take care of... I can't see many other than AC_CHECK_LIB WMP> and testing for module-specific includes. But creating the makefiles, etc, WMP> etc, is definitely best left to the modules themselves. WMP> I've been meaning for well over a year to make the package system use WMP> autoconf, but have never found the time. :( Time.... One idea is that the module needs an XEmacs, and XEmacs already knows _everything_ about the system. And its configuration variables are available from lisp via config-value-hash-table. Perl does something similar with its modules. perl Makefile.PL make make install Note: no independent configure step. Just ask the perl executable.

* "Martin" == Martin Buchholz <martin(a)xemacs.org&gt; writes: SY> Does it even need to be in the core distribution at all? I don't mean SY> that I don't think XEmacs needs ViaVoice support. What I'm saying is, SY> why can't you package your ViaVoice module separately from the core, SY> with its own configure/build process? Martin> That is the "architecturally correct" way to do it. But in practice Martin> it's probably reasonable to add a hack to our configure.in so that an Martin> external package doesn't have to maintain one. I must be missing something here, how does that make any sense? Wouldn't that restrict the package to being only distributed with XEmacs, or at least only able to build the package when you build XEmacs itself? -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|