emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress


From: Stephen Leake
Subject: Re: Dynamic loading progress
Date: Sat, 18 Oct 2014 16:06:21 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt)

Stefan Monnier <address@hidden> writes:

>>>> - how should modules be packaged?
>>> As GNU ELPA packages, of course.
>> Several headers are needed in order to build a module, and they have
>> to be the one your current Emacs was built with (eg config.h).
>
> Right, those headers need to be provided by Emacs.
>
>> I think this means Emacs should copy those in the system include dir
>> when installing.
>
> If we let Emacs run the C compiler, it can trivially add the -I args
> to specify where those headers are found.  This way they don't need to
> be installed in the system's include dir (which is always a problem for
> non-root users, and makes it more tricky to handle multiple installs of
> different Emacs versions).

Let's not assume C; I'm planning on writing a module in Ada, with a
Makefile and Ada compiler config files.

One step in the Makefile will be to generate Ada import headers from the
C headers, so I do still need those headers.

Another module I'm planning will have texinfo sources; that needs to run
'makeinfo'.

It would be excellent if 'package install' could run an arbitrary
script, assuming the user has the required tools on PATH. (It would also
be nice if the script gave good error messages about missing tools, but
that's not Emacs's problem).

Emacs could export an environment variable (or more than one) providing
the location of the Emacs C headers.

Perhaps the package meta information could specify whether to run gcc
with -I, or to run an arbitrary build script with environment vars.


Just requiring that a compiler be installed will put off a large number
of users, so a binary distribution would be nice.

For binary distributions, or sources with lots of other dependencies, an
option is to provide the non-elisp code as an OS package thru the
standard OS distribution mechanisms. Debian and Mingw64 packages would
cover a lot of users (although I have some using Mac; I know nothing
about packaging on Mac, except it seems to be harder than anywhere else).

Then the ELPA module can list that as a dependency, and simply tell the
user to install it outside Emacs if the package load fails.

Or the package build script mentioned above could invoke the appropriate
OS install commands.

The OS distribution mechanisms have a lot of support for building
things; let's not reinvent that wheel.

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]