Re: A couple of problems with new module code.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> If it was intended to be used by or with the core in any
Jerry> way, I would agree.
It's not a question of the code produced, it's a question of "do we
need to cause annoyance to testers and sysadmins who may have good
reasons to want to use modules?" I don't think we should.
We won't. Those scripts aren't used at all in the current setup. They
are for future use, when we get to the point that distributing modules
separately from the core makes sense. Until then, that code is
inactive. I have verified that it works *for me*, but there is no
support for actually building and installing modules separately from the
core. Hence, the testers and sysadmins only need autoconf 2.13.
I think it would be best to stick to autoconf 2.13, but I don't
want
to make you do extra work when there's a reasonable chance that 22.0
will use autoconf 2.5x. Is it known to be unreasonable for simple
autoconf.in's to be compatible with both 2.13 and 2.5x?
I don't know. I'm not exactly an autoconf wizard. I can make the
attempt, I suppose, but I still don't see the point in doing so.
OK. Maybe they need to check the installed XEmacs for the error
behavior? (Yes, I know that's a hairball....) Er, wait a sec ... do
they produce their own config.h? That's not good.
No, they don't. They ask ellcc for the location of config.h. It
already has the behavior you suggested for --use-config-h. Check out
the --mod-archdir flag.
If that XEmacs uses pdump, you could also build in the pdump-id to
make sure the binary and the modules correspond (I think, I don't
really understand the pdump-id).
I don't think that will be necessary, given the mechanism I describe
below. If you see problems with that mechanism, let me know, of course.
Jerry> We could remove the ability to build the modules
separately
Jerry> for now, if that seems wise to the other developers.
I don't think so. We are either going to face this breakage
eventually, or give up on independent modules. But (aside from RMS's
bete noire of a backdoor through the GPL), packaging ELLs is the main
generic[1] reason for doing this, right? Let's do it now; someone
who's not working on modules can always get a working XEmacs with
./configure --with-modules=no, right?
Yes, that is correct.
The problem is that the modules evidently depend on the
configuration
of the XEmacs they run with. We need to understand why and fix the
API / advice to modules programmers / ABI.
The ellcc tool is *supposed* to handle all of this. When it is built,
it remembers the flags passed to the compiler when XEmacs itself is
built, and passes those same flags to the compiler for module building.
(This means that you have to use the same compiler.) The header files,
including config.h, are stashed away in $MOD_ARCH_DIR/include, where
they are snarfed by ellcc to give the same build environment. That's
why Steve's problem is so weird. It looks like the wrong ellcc is being
invoked, but I don't see how that could happen.
[1] I know you and Andy Begel have other reasons for wanting
modules,
I'm talking about why the rest of us want them. ;-)
I've gone so far off on a tangent from my original reason for wanting
modules that there's little point in looking back now. :-) Besides, IBM
appears to have given up on ViaVoice for Linux (*sob*).
--
Jerry James, currently reading
<URL:http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/clocc/clocc...
for fun
http://www.ittc.ku.edu/~james/