| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
This also writes the metadata from both the single file package and the
multi-file package code-path
|
| |
|
|
|
| |
The idea is to pass some of what emacs knows about the package back
to (perl) debhelper. So far only name and version are written
|
| |
|
|
|
| |
We only do this if passed a working directory. The protocol is maybe a
bit odd, but filtering the output from emacs looks messy.
|
| | |
|
| | |
|
| |
|
|
| |
In principle it might be nice to automate synching this, but since falling out of sync is mainly an aesthetic problem afaik, ignore that problem for now.
|
| | |
|
| |
|
|
| |
Still no byte compilation, and grotesque amounts of output
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out this isn't $MESSY_CONFLICT_ZONE, there are rules about
writing debhelper extensions.
This is mainly cargo culting from dh_installdocs.
- compute destination directory, support multiple binary packages.
- add debian/elpa file, test the "standard" codepath. Still not very
standard because it's a single file elpa package.
|
| |
|
|
| |
Not sure this is really useful, but I guess it doesn't hurt.
|
| |
|
|
| |
I guess this is a bug in the package.el I borrowed this code from.
|
| | |
|
| | |
|
| |
|
|
| |
just grab the package.el version, and add directory parameter
|
| |
|
|
|
| |
- don't compile or activate package
- take destination directory as a parameter
|
| |
|
|
| |
credit where credit is due.
|
|
|
One function "borrowed" from package.el. We don't want to rely on the
private (seeming) API, and anyway it's easier to modify certain
aspects, like byte compiling.
|
