Jerry> It appears that the consensus from the discussion following Jerry> my earlier modules question was that: Jerry> a) I should do my own autoconf magic (which, as somebody Jerry> mentioned, wasn't all that hard); and Jerry> b) I should structure my module so that it can be Jerry> compiled outside of the XEmacs source tree (i.e., make it Jerry> an external module). Jerry> For the information of whoever is responsible for modules Jerry> (I don't see anyone listed on Jerry> <URL:http://xemacs.sourceforge.net/Develop/jobs.html>), Jerry> here are the obstacles I have encountered so far in Jerry> accomplishing (b), working with the XEmacs 21.2.37 Jerry> distribution: Jerry> 1) Missing header files. Jerry> a) emodules.h is not installed anywhere when XEmacs is Jerry> installed, so I can't very well include it. Jerry> b) A bunch of other header files, needed by Jerry> emodules.h, are also not installed. These include Jerry> lisp.h, sysdep.h, window.h, buffer.h, etc. Jerry> Incidentally, speaking of installed header files, why Jerry> are the entire s&m directories installed in Jerry> .../lib/xemacs-21.2-b37/config-name/include? It's a Jerry> machine-specific directory, so why do I want header Jerry> files for every machine under the sun? Jerry> 2) Lack of examples. Jerry> a) The examples in the modules directory of the XEmacs Jerry> distribution are all of internal modules. That is, Jerry> they only build inside the XEmacs source tree. And Jerry> even then, they aren't right. They only build inside Jerry> the source tree *if you built XEmacs itself inside the Jerry> source tree*. If you, like me, build XEmacs for Jerry> multiple platforms, and therefore use VPATH to build Jerry> outside of the source tree, the modules won't build at Jerry> all, due to assumptions about the location of ellcc Jerry> and make-docfile. Jerry> b) The example Makefiles (and, strangely, not the Jerry> README in the modules directory) all refer to "samples Jerry> in the sub-directory 'installed'" to show how to write Jerry> modules to be compiled outside of the XEmacs source Jerry> tree. That subdirectory is not part of the XEmacs Jerry> 21.2.37 distribution, the comments are in the wrong Jerry> place, and I doubt that such examples even exist due Jerry> to problem #1. Jerry> I am willing to be a guinea pig to help get external Jerry> modules working, but I need some direction from the list Jerry> and whoever is coordinating module development. Would that be you, Gunnar? Jerry> Regards, Jerry> -- Jerry> Jerry James -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

Steve Youngs <youngs(a)xemacs.org&gt; wrote: [snip] I did configure --with-modules, and emodules.h and the other header files did not get installed by "make install". Is it possible that this is because I built outside of the XEmacs source tree? As I noted, the existing modules examples assume that you are building inside the XEmacs source tree. Are the Makefiles constructed that way, too? I just did a grep on the XEmacs 21.2.37 source tree. The string "emodules.h" does not appear in any file with a name of the form *.in, which means that it won't be in any Makefile, doesn't it? Where is the rule for installing emodules.h? In fact, grepping for just "emodules" in all files doesn't turn it up anywhere where I would expect an install rule to be able to grab it. What am I missing? One whopping big one, yes. :-) I've got some basic functionality working, as of last night (hooray!), namely connecting with the ViaVoice engine, defining a simple (one word) grammar, and retrieving the single recognizable word as it is spoken. Now I get to learn all about XEmacs events. He already has, in the sense that I've been through his base64 and zlib examples many times, looking for answers to my questions. -- Jerry James

Sho' 'nuff. 2000-12-01 Jerry James <james(a)eecs.ukans.edu&gt; * Makefile.in.in: Use the loop variable to install headers. --- src/Makefile.in.in.ORIG Tue Oct 3 03:26:55 2000 +++ src/Makefile.in.in Fri Dec 1 14:08:02 2000 ＠＠ -741,7 +741,7 ＠＠ cd ${srcdir}; hdrdir2=`pwd`; cd $$hdir; \ test "$$hdrdir2" != "$$hdir" && hdir="$$hdir $$hdrdir2"; \ (for thisdir in $$hdir; do \ - cd $$hdir && \ + cd $$thisdir && \ (hdrtars=; \ for hdrfile in *.h; do \ hdrtars="$$hdrtars $$hdrfile"; \ Oh, I am. Work on it has slowed down a bit this week, though. It couldn't possibly have anything to do with the birth of my daughter on Monday, I'm sure. :-) -- Jerry James, proud father (for the 3rd time, yikes!)

If you build *inside* the XEmacs source tree, then it is not necessary, since $hdir contains only one value, and therefore $thisdir == $hdir, and the loop is executed exactly once. If you build *outside* the XEmacs source tree (like I do, due to supporting multiple architectures), then it is necessary, since $hdir contains two values. As the code stands, it will cd to the same directory (the build directory, as it happens) on both iterations of the loop and so will fail to ever cd to the source directory containing header files. The loop is executed twice, but does the same thing both times. Try building outside the source tree. The header files don't get installed. -- Jerry James