Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> * "Jerry" == Jerry James <james(a)eecs.ukans.edu> 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.
Aiiigh! Configure is not that difficult. XEmacs' configure is hairy,
nasty, and has big nasty teeth, yes. But that is because it is a much
larger beast than a plugin module for it needs to be.
Modules SHOULD have a separate configure stage - this way they can test for
whether the emacs they are compiling against is XEmacs 21.1, 21.2, etc,
etc, and do appropriate things.
For actual OS things that they would need to check for that XEmacs'
config.h doesn't take care of... I can't see many other than AC_CHECK_LIB
and testing for module-specific includes. But creating the makefiles, etc,
etc, is definitely best left to the modules themselves.
I've been meaning for well over a year to make the package system use
autoconf, but have never found the time. :(
-Bill P.