Ville Skyttä <ville.skytta(a)xemacs.org&gt; writes: Great! I added sml-mode and docbookide, but ecb didn't compile: [jas＠latte ecb]$ make xemacs -no-autoloads -batch -l /home/jas/src/packages/package-compile.el -- xemacs-base semantic eieio fsf-compat edit-utils jde mail-lib eshell ediff -- -l overlay -l compile -l timer -l ecb-util -l ecb-eshell -l ecb-layout -l tree-buffer -l esh-mode -l em-dirs -l jde-help -l semantic -l semantic-load -l semanticdb -l sendmail -l ediff-init -f batch-byte-compile ecb-compilation.el Loading /usr/local/lib/xemacs-21.4.9/lisp/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/ediff/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/eshell/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/mail-lib/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/jde/lisp/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/edit-utils/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/fsf-compat/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/eieio/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/semantic/auto-autoloads... Loading /data4/jas/laptop/src/packages/xemacs-packages/xemacs-base/auto-autoloads... # bind ( stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) signal(void-variable (eshell-directory-name)) # bind (data error-symbol) signal-error(void-variable (eshell-directory-name)) # bind (error-data) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Symbol's value as variable is void: eshell-directory-name xemacs exiting . make: *** [ecb-compilation.elc] Error 255 [jas＠latte ecb]$

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SJT> Steve: is there some way that people with commit privileges can be SJT> allowed to create packages in CVS without interfering with your work? SJT> I'm thinking about something like adding a SJT> .../alpha-packages/$developer-name/$package-name hierarchy parallel to SJT> the "official" .../packages/xemacs-packages hierarchy. Sure. I'll create directory under XEmacs/packages/ called "unsupported". With a README containing the appropriate warnings and disclaimers. I'd rather call it "unsupported" than "alpha-packages" to reduce confusion. SJT> I'm just guessing, but probably we can just drop the standard SJT> makefiles and XEmacs.rules (maybe with STAGING defaulting to somewhere SJT> other than the usual "official packages" STAGING) in there. More than likely. My only requirements are what I mentioned in another post to this thread. Namely: - They install to /site-packages/ - They don't have a _pkg.el file. - They don't have a package-index file. Those last two points will change, but PUI needs enhancing first. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SY> - They install to /site-packages/ SJT> Er, how do we do this currently? Simple answer... we don't. We can't do it with PUI anyway (until I extend it to cope). The way I see it, the developers of these types of packages currently have two choices: 1) Distribute the package as a source tarball and the user does a 'make install'. The install Makefile target would compute the value of 'emacs-roots' and install to ${emacs-roots}/lib/xemacs/site-packages/ (they could also go in ~/.xemacs/site-packages/) 2) Distribute the package as a binary tarball who's top level directory is site-packages/. With instructions for the user to unpack to either ${emacs-roots}/lib/xemacs/ or ~/.xemacs/ SJT> In particular, make bindist doesn't understand the difference SJT> among {xemacs,mule,site}-packages.. 'make bindist' doesn't need to make a distinction between the various package directories. In the top level of a binary package tarball you'll see: etc/ info/ lib-src/ lisp/ man/ pkginfo/ Not: {xemacs,mule,site}-packages/ -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SY> 'make bindist' doesn't need to make a distinction between the SY> various package directories. In the top level of a binary SY> package tarball you'll see: SJT> I understand that, sorry, I wasn't clear. You see, I do both a local SJT> install and a make bindist for my slower machines ..... This seems to SJT> work, except that my Mule and local packages end up installed to SJT> xemacs-packages. OK, I think I know what you're getting at. 'make bindist' sets $(STAGING) to $(XEMACS_STAGING). I like this behaviour because it puts all the package tarballs whether Mule or not into the same directory. And, more importantly, if 'make bindist' simply obeyed $([XEMACS,MULE]_STAGING) you would end up with two package-index files. IMO, 'make bindist' should rm -rf the subdirectories it leaves in $(STAGING) (etc/ lisp/ info/ etc).[1] 'make install' will set $(STAGING) to either $(XEMACS_STAGING) or $(MULE_STAGING) depending on the package's category. SJT> Do I have to change STAGING every time to avoid this? If you're mixing 'bindist' and 'install' builds you're likely to run into trouble. But there's more than one way to skin a cat. If you can spare the disc space, change... ,----[ Local.rules ] | ifeq ('$(MAKECMDGOALS)','bindist') | STAGING := $(XEMACS_STAGING) | endif `---- to... ,----[ Local.rules ] | ifeq ('$(MAKECMDGOALS)','bindist') | STAGING := /a/different/path/to/other/staging/directories | endif `---- And then do 'make bindist'. Use the tarballs for your other machines, and delete the subdirectories that get left behind. For your local machine, simply do 'make install'. To take this a step or two further... On the machine where you build the packages: - ln -s $(XEMACS_STAGING) /usr/local/lib/xemacs/xemacs-packages - ln -s $(MULE_STAGING) /usr/local/lib/xemacs/mule-staging - make the "bindist $(STAGING)" accessible to your other machines via FTP (this assumes of course that there is some kind of link between your machines) On your other machines: - (setq package-get-remote '("your.server.host" "/path/to/bindist/staging/")) - (setq package-get-base-filename "package-index") - M-x pui-list-packages RET Have I explained that well enough? How does it suit your needs? Footnotes: [1] Maybe not. I does give me the opportunity to quickly check that all the files for a package have been installed properly. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

On Mon, 10 Jun 2002, Steve Youngs said: Oh bugger. I guess i'll have to fix preview-latex: it creates a _pkg.el file in site-packages/preview, as normally installed. (What harm does it do? I couldn't spot any, and I thought I looked...) Are they temporary enough to make it not worth bothering removing _pkg.el creation from preview-latex? -- `What happened?' `Nick shipped buggy code!' `Oh, no dinner for him...'

On Mon, 10 Jun 2002, Steve Youngs stated: Um. That's what I meant to say, and that's where I put it :) My keyboard must be broken. ;} Argh, gak. How much of the pkginfo/info/_pkg.el/MANIFEST machinery do I need to remove? Just _pkg.el? -- `What happened?' `Nick shipped buggy code!' `Oh, no dinner for him...'

|--==> "n" == nix <nix(a)esperi.demon.co.uk&gt; writes: n> How much of the pkginfo/info/_pkg.el/MANIFEST machinery do I need to n> remove? Just _pkg.el? You just need to remove the autoload cookie from _pkg.el and re-generate your auto-autoloads.el file. But... I've just added stuff to unsupported/ that will build unsupported packages without you having to worry about this kind of thing. Basically, it's a modified clone of what's in the top level packages directory. BTW, Nix, do you want to put preview-latex into 'unsupported/'? -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|