|--==> "ML" == Mats Lidell <matsl(a)contactor.se> writes:
ML> Hi,
ML> This is not a serious patch, thus not posted to patches, but is to set
ML> focus on a problem, and probably not a serious one ;-), in the making
ML> of ps-print.
Just checked the other packages... ps-print is the only one with this
problem. Phew! No huge sweeping patches. :-)
ML> The mule sources are ifeq'ed but before the inclusion of
ML> XEmacs.rules. Thus all el-files are included when building ps-print
ML> without mule. (As it happens this seems to be OK. The files are
ML> compiled.)
ML> On the other hand when XEmacs.rules is included before the ifeq, so
ML> that the files are left out in a none mule build, I found out that
ML> ps-mule is actually needed by ps-print.
[...]
ML> -ELCS = lpr.elc ps-print.elc
ML> +ELCS = lpr.elc ps-print.elc ps-mule.elc
ML> -ifeq ($(BUILD_WITHOUT_MULE),)
ML> -ELCS += ps-mule.elc ps-bdf.elc
ML> -endif
[...]
ML> +
ML> +include ../../XEmacs.rules
ML> +
ML> +ifeq ($(BUILD_WITHOUT_MULE),)
ML> +ELCS += ps-bdf.elc
ML> +endif
Just wondering, how much trouble would we get into if we were to not
try to make any distinction between Mule and non-Mule? In other
words, include both ps-mule.el and ps-bdf.el in non-Mule builds.
Could somebody with a bit of Mule savvy have a look at that for me and
let me know if it would be OK. Steve T?
Mats, thanks for bringing this up.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|