Re: [Geiser-users] Easier way to ELPA-ize Geiser

[Jose A. Ortega Ruiz]

On Sun, Sep 30 2012, Daniel Hackney wrote:

> (I'm not on the geiser-users list, so please CC me on future messages)
>
>> On Fri, Sep 28 2012, Daniel Hackney wrote:
>>
>> > I wanted to update to version 0.2.1 and figured I'd solve the issue of
>> > integrating with package.el once and for all. I made a script to change
>> > Geiser into an ELPA package in a fully-automated way. The script is
>> > here: https://gist.github.com/3798214 and must be run from within the
>> > untarred directory of "geiser-0.2.1.tar.gz"
>>
>> Excellent!  Grant Rettke has also created a package recently
>> (http://www.wisdomandwonder.com/article/6408/geiser-0-2-1-elpa-package),
>> and i was thinking about integrating the packaging process into
>> Geiser's build system one of these days.
>
> Cool! You know you're on the right track when someone else is trying to
> solve the same problem :)
>
>> If you don't mind my stealing it,
>
> Of course not! I updated the gist and added a GPLv3 header.

Thanks!  (I'm actually using it just in spirit: my "script" is a
makefile rule doing similar things in shellish ways.)

>> rule and with some simplifications when i can move things to Geiser's
>> side (like autoload cookies), will make possible to just do 'make
>> elpa' in a source checkout to build the ELPA package.
>
> Adding autoload cookies would simplify things a bunch. Most of the Elisp
> code in the script is adding autoload cookies and removing unneeded
> settings of `geiser-elisp-dir' and `geiser-scheme-dir'.
>
> With some structural modifications, you could make it so that no make
> script needs to be run at all. It would entail putting all of the elisp
> and info files in the root directory, but not much aside from that.

Since i'm using make for maintanership, it's very easy for me to use a
make rule for creating the package (what i'm not doing in that rule is
running make install; there it's not needed).

>> I can then set up an ELPA repo in Geiser's download area, and also
>> upload it to Marmalade (if we can solve the problems Grant and I
>> encountered with the latter these days) on every new release.
>
> That would certainly be the easiest way to do things. Users could then
> install geiser without having to think about it at all :)
>
>> P.S: BTW, Grant and i added a 'dir' file to make Geiser's info file
>> visible in Emacs out of the box: does it work for you that way without
>> that file? (i.e., does Geiser's manual appear in the info top level
>> index?)
>
> The way my script did things resulted in Geiser's info page being
> visible in the info directory. I think all that is needed is to have a
> "dir" file at the root and the associated "*.info" files next to it.

Yeah.  That dir file was created by 'make install'.  I'm doing something
similar.

> P.S.: I saw that you made a change just now, adding autoload cookies to
> geiser.el. Adding autoload cookies to `autoload' calls is pretty
> redundant; better just put the cookies before the actual function and
> variable definitions. The only reason I did it like that in my script
> was for simplicity. If you're actually modifying the source, you should
> definitely put the cookies above the appropriate `defun' and/or
> `defvar'.

I want to keep a separate list of autoloads in geiser.el because calling
(load-file "geiser.el") is the way to run the package directly from a
git checkout, with zero configuration and no installation.  For people
like me maintaining the source, that's a big boon, and external users
are not gonna be affected by this redundancy :) -- basically, i'm adding
the cookies for ELPA's benefit (i also happen to prefer a explicit list
while developing rather that having to generate it; it just makes things
easier.)

Cheers,
jao
-- 
I don't necessarily agree with everything I say.
 -Marshall McLuhan (1911-1980)