10:21 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> * "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp>
writes:
>>>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> This causes emu-mule.el (and some
others requiring mule) not
APA> to be byte-compiled when the package is built.
Stephen> Do you mean that such files are sprinkled around outside
Stephen> of the xemacs-packages/mule sources? If so, can you
Stephen> suggest a way for me to quickly identify them (eg, grep
Stephen> for BUILD_WITHOUT_MULE in package Makefiles)?
Stephen> I would like to purge code that requires Mule to build
Stephen> correctly from the main codebase.
SY> Please don't. Having packages split across two different
SY> places will make maintenance a bitch.
Yeah Steve, you catch my drift.
This was exactly the concern I tried to convey to Stephen.
Building a package is just not as simple as marking all .el files in a
dired buffer and byte-copmiling them all.
But
make distclean
make bindist
isn't really asking too much of people who want to build their own
packages, I think.
Having to copy xemacs-packages/Local.rules.template to
xemacs-packages/Local.rules and configuring it correctly is the
trickiest part.
We should probably have a xemacs-packages/README file explaining this
and advertising xemacs-packages/NEWS.packages as well.
Steve, are you willing to write that file?
Adrian
SY> But what you could do is add a 'PROBLEMS' file to each
SY> non-Mule package that contains Mule files. [1] [2]
SY> ,----[ ./PROBLEMS ]
SY> | This package contains files that will only byte-compile using a
SY> | Mule-enabled XEmacs.
SY> |
SY> | Those files are: x.el, y.el, z.el ...
SY> |
SY> | If your XEmacs is not Mule-enabled, don't panic, this package does not
SY> | lose any functionality by not having the above files byte-compiled.
SY> `----
SY> These are the packages that have Mule files... [3]
SY> ,----[ find -name "Makefile" -exec sh -c 'grep -H
"_MULE" {}' \; ]
SY> | ./comm/footnote/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./comm/mew/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./comm/mew/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./comm/tm/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./libs/apel/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/edict/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/egg-its/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/leim/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/locale/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/mule-base/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./mule/skk/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./oa/calendar/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> | ./wp/auctex/Makefile:ifeq ($(BUILD_WITHOUT_MULE),)
SY> `----
SY> Footnotes:
SY> [1] I know that this isn't the cleanest of solutions, but I think its
SY> a pretty good trade-off between ease of maintenance and user
SY> complaint. So far, I've only seen one complaint like this (the
SY> one that started this thread).
SY> [2] Just mail them to me and I'll add them to the CVS tree.
SY> [3] Obviously the packages under ./mule/ don't need this
SY> 'enhancement'.
SY> --
SY> |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---|
SY> | XEmacs - It's not just an editor... |
SY> | It's a way of life. |
SY> |----------------------------------<mailto:youngs＠xemacs.org>---|
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org
10:02 a.m.
New subject: byte-compile emu-mule.el
* "APA" == Adrian Aichner <adrian(a)xemacs.org> writes:
APA> We should probably have a xemacs-packages/README file explaining this
APA> and advertising xemacs-packages/NEWS.packages as well.
APA> Steve, are you willing to write that file?
It is actually on my todo list. But because it is writing doco (and
lets face it, who likes writing doco), it has gotten buried quite deep
into the todo list. :-( Perhaps I should resurrect it.
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
10:58 a.m.
New subject: byte-compile emu-mule.el
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
Stephen> I would like to purge code that requires Mule to build
Stephen> correctly from the main codebase.
SY> Please don't. Having packages split across two different
SY> places will make maintenance a bitch.
"Purge" doesn't necessarily mean physically move (or remove), although
that's what Yoshiki and I recommended for APEL's emu-mule.
The problem is that _code containing Mule characters is not Lisp_ as
far as a --with-mule=no XEmacs is concerned. A README.mule really
isn't sufficient for this. Attempting to load such a file leaves Lisp
in an undefined (from the user's point of view) state: definitions and
top-level code encountered before the top-level sexp containing the
first Mule character _will_ have been executed, except that function
definitions and provides will get unwound in the case of an autoload.
I have three different approaches in mind
o physically move the code to a separate package directory,
probably with the same name, under xemacs-packages/mule
o physically move the code to a mule subdirectory of the original
package
o physically move the code to a separate file with an extra
extension (.mule should do the trick)
In the former case, we'd need to create a separate package; that
probably is a distribution nightmare, so it probably hardly ever makes
sense. The last is probably the best idea; there actually is very
little code that really requires Mule. Then XEmacs.rules would get a
rule to make a .el file from a .el.mule file by renaming or copying
it.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> But
APA> make distclean
APA> make bindist
APA> isn't really asking too much of people who want to build
APA> their own packages, I think.
Actually, it's a fair amount. It's often quite hard to determine
which packages you need ex ante, so basically you end up checking out
the whole xemacs-packages tree. This could probably be mostly fixed
with a dependency chaser, but most package build bugs reported seem to
be due to dependency bugs in one form or another.
APA> Having to copy xemacs-packages/Local.rules.template to
APA> xemacs-packages/Local.rules and configuring it correctly is
APA> the trickiest part.
I hate that name; there are no Make rules in that file, and shouldn't
be. I guess it's too late to change, though.
APA> We should probably have a xemacs-packages/README file
APA> explaining this and advertising xemacs-packages/NEWS.packages
APA> as well.
Actually, we should have a Packages chapter in the Lispref.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:25 p.m.
New subject: byte-compile emu-mule.el
* "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> I have three different approaches in mind
Stephen> o physically move the code to a separate package directory,
Stephen> probably with the same name, under xemacs-packages/mule
Stephen> o physically move the code to a mule subdirectory of the original
Stephen> package
Stephen> o physically move the code to a separate file with an extra
Stephen> extension (.mule should do the trick)
Stephen> In the former case, we'd need to create a separate package; that
Stephen> probably is a distribution nightmare, so it probably hardly ever makes
Stephen> sense. The last is probably the best idea; there actually is very
Stephen> little code that really requires Mule. Then XEmacs.rules would get a
Stephen> rule to make a .el file from a .el.mule file by renaming or copying
Stephen> it.
Approach 3 looks the best. But it will only help people who build
from the CVS source. Anyone else is going to have all those *.mule
files as *.el because I build with Mule-enabled XEmacs.
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
8775
days inactive
8777
days old
3 comments
3 participants
participants (3)
-
Adrian Aichner -
Stephen J. Turnbull -
Steve Youngs