[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `make' written in elisp
From: |
Stefan |
Subject: |
Re: `make' written in elisp |
Date: |
Sun, 02 Jan 2005 19:26:41 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (darwin) |
> Judging from the comments, this installer might more or less get along
> at least with some XEmacs packages, as well as some other packages
> with a regular enough structure (AUCTeX has in the mean time gotten a
> new autoconf-based installer very similar to that of preview-latex, so
> the latest versions probably will not work with install.el).
It might still work, depending on how the configuration is done. I tend to
think that most of the autoconfiguration should be done upon use rather
than during installation, which basically implies "in elisp rather than in
autoconf".
> a) a directory layout. XEmacs packages have a standard way of placing
> Elisp, info, data and other files in a layout under the top package
> directory. In addition there are some standard file names for
> initializing of packages and installation. In short, this part of the
> package system is basically just file layout conventions relative to a
> package-specific top directory.
> We don't have any conventions for packages intended for Emacs as far
> as I can see. It certainly would not be bad to have something like
> that: if people make code for Emacs, and if we can agree on some
> layout that makes it easier for stuff to work out of the box, it
> certainly might be worthwhile to state some conventions.
Yes, `install' does not impose a particular structure (it just looks
recursively for *.el files). But it would benefit from some conventions
(so it can safely ignore the contrib/foo.el or compat/bar.el files).
I can't find any documentation about the in-package layout used by XEmacs,
tho. Anybody knows where it's described?
> b) version management. Versions must basically be floats, higher
> versions correspond to later versions, are usually based on some CVS
> archive and not at all with actual package versions. Uh.
Right, it seems to be used only to discover whether a newer version is
available or not.
> c) a package manager that will download and upgrade packages. It
> might do so in user-specific and system-wide packages.
> d) central download archives that will provide all packages, updated
> by packagers (often different from the actual creators of software) on
> central servers.
> e) it does not offer AFAIR: dependencies and standard tests (for
> executables, directories and other stuff) that autoconf provides. A
> bit of framework for that might be nice for obliterating some
> necessities for installation. Even though installing MSYS is not
> particularly hard, it still seems to be a barrier for some people.
`install' doesn't get involved with version management, dependencies, ...
It only tries to make it easier for users to install and setup external
packages. A package manager to also allow activation/deactivation/deletion
would be a natural addition.
> I am not convinced about the value of the centralized server approach
> to package management from XEmacs: it does not seem to lend itself
Since `install' specifically targets external packages, a centralized server
doesn't make much sense indeed. For XEmacs, it was probably
a good simplification.
> But I do think that we should try to offer some way of installing
> external Lisp code if one has acquired it as a zip or tar archive in
> some manner already.
Not just tarballs but also single elisp files. Most elisp packages are
single files.
> And in those respects where the directory structure and layout
> conventions of an XEmacs package would seem reasonable, there seems
> little point in inventing something else.
Agreed.
> Stefan, having met those problems when writing install.el already,
> would probably be a lot more qualified to comment on my impressions
> and on the versatility of the package layout he has been catering for.
The DWIM-aspect of `install' (just look for *.el and *.info files) only
works up to a point. I've bumped into problems where some *.el files should
be ignored, or other problems where the *.info file doesn't have the `info'
extension, or where the info file simply doesn't exist and it's not clear
how to build it based on a bunch of *.texi files, ...
We could keep adding intelligence and heuristics, but it makes more sense to
devise some conventions.
> All of those certainly sound reasonable. In particular, I'd second having
> separate commands for installing system-wide and user-local packages.
Agreed, it makes more sense.
Stefan
PS: I attached my latest version, which is still "work in progress".
install.el
Description: application/emacs-lisp
- Re: `make' written in elisp, (continued)
- Re: `make' written in elisp, Ralf Angeli, 2005/01/03
- Re: `make' written in elisp, Richard Stallman, 2005/01/03
- Re: `make' written in elisp, Ralf Angeli, 2005/01/03
- Re: `make' written in elisp, David Kastrup, 2005/01/03
- Re: `make' written in elisp, Richard Stallman, 2005/01/03
- Re: `make' written in elisp, Ralf Angeli, 2005/01/04
Re: `make' written in elisp,
Stefan <=
- Re: `make' written in elisp, Stephen J. Turnbull, 2005/01/03
- Re: `make' written in elisp, Stefan Monnier, 2005/01/03
- Re: `make' written in elisp, Stephen J. Turnbull, 2005/01/04
- Re: `make' written in elisp, Stefan, 2005/01/04
- Re: `make' written in elisp, Miles Bader, 2005/01/04
Re: `make' written in elisp, Eric M. Ludlam, 2005/01/04