Re: A couple of problems with new module code.
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
> Wrong. Don't upgrade requirements to >= while something
else
> (the core, yet!) requires <=. It's a massive pain in the ass,
> because some people won't have one or the other, and those who
> have both will make varying decisions about the default. If
> that file works with autoconf 2.13, just copy it to
> configure.in.
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.
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?
Jerry> But those configure scripts are only to be used when the
Jerry> module is built independently of the core
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.
How about a --use-config-h=REQUIRED_FILE_SPEC option, which defaults
to
`xemacs -vanilla -batch -eval '(princ exec-directory)'`include/config.h`?
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).
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?
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.
Footnotes:
[1] I know you and Andy Begel have other reasons for wanting modules,
I'm talking about why the rest of us want them. ;-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py