path: root/dh_elpa
Commit message (Collapse)AuthorAge
* replace dependency on File::SlurpDavid Bremner2015-07-13
| | | | Hopefully I'm doing this "read back the temp file" thing correctly
* compute elpa package name from debian binary package name.David Bremner2015-07-13
| | | | This is probably not the best solution, but it works for now.
* add function to only print command output on error.David Bremner2015-07-13
| | | | A refined version of this should perhaps be pushed into debhelper.
* Initial support for multiple-file packagesDavid Bremner2015-07-12
| | | | Still no byte compilation, and grotesque amounts of output
* minimal conversion to perl / debhelper libDavid Bremner2015-07-12
| | | | | | | | | | | | 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.
* hack to add dh-elpa.el to load-pathDavid Bremner2015-07-11
| | | | This would all be easier if I didn't insist on using emacs -Q
* use package.el magic to find the lisp fileDavid Bremner2015-07-11
| | | | | Since the whole point of this package is to simplify other packages, try to set a good example.
* make dh_elpa actually work with an installed elisp file.David Bremner2015-07-11
| | | | | This is not the most elegant solution in the world, but impovements only need to change this package's debian/rules.
* start a simple wrapperDavid Bremner2015-07-11
Scripts using emacs lisp require wizard level hackishness to get execed. Let's do things the simple way.