Elpa packages and Makefiles

Elpa packages and Makefiles

[Eric Abrahamsen]

I'm slowly working on a getting a package Elpa-ready, and have just a
few more questions. One is the role of a Makefile.

The only targets I really need are compilation, autoloads, and texinfo.
My understanding is that Elpa deployment will do all these things for me
(the last dependent on the presence of "<package>.texi" and "dir"
files). I don't need a Makefile for that.

But I would like to also make the package installable straight from
github or other locations, in which case a Makefile will still be
necessary.

In the Elpa repo I've seen packages with Makefiles, with no Makefiles,
and even with Makefiles that contain an "elpa" target. My question is,
will Elpa deployment honor an existing Makefile (in which case, which
targets are used?), ignore it, or conflict -- ie I should .elpaignore it
or something.

Thanks!
E

Re: Elpa packages and Makefiles

[Grant Rettke]

To think through the process and decide how you would package it up
yourself, try setting
up an el-get recipe: https://github.com/dimitri/el-get

Once you've got that thought through, you will be able to get any
package maintainer whatever they need to package up your software
because you will know precisely what steps you wanted to be performed.
Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Fri, Jul 11, 2014 at 10:26 PM, Eric Abrahamsen
<eric@ericabrahamsen.net> wrote:
> I'm slowly working on a getting a package Elpa-ready, and have just a
> few more questions. One is the role of a Makefile.
>
> The only targets I really need are compilation, autoloads, and texinfo.
> My understanding is that Elpa deployment will do all these things for me
> (the last dependent on the presence of "<package>.texi" and "dir"
> files). I don't need a Makefile for that.
>
> But I would like to also make the package installable straight from
> github or other locations, in which case a Makefile will still be
> necessary.
>
> In the Elpa repo I've seen packages with Makefiles, with no Makefiles,
> and even with Makefiles that contain an "elpa" target. My question is,
> will Elpa deployment honor an existing Makefile (in which case, which
> targets are used?), ignore it, or conflict -- ie I should .elpaignore it
> or something.
>
> Thanks!
> E
>
>

Re: Elpa packages and Makefiles

[Eric Abrahamsen]

Grant Rettke <gcr@wisdomandwonder.com> writes:

> To think through the process and decide how you would package it up
> yourself, try setting
> up an el-get recipe: https://github.com/dimitri/el-get
>
> Once you've got that thought through, you will be able to get any
> package maintainer whatever they need to package up your software
> because you will know precisely what steps you wanted to be performed.

Thanks, Grant. In this case, I *am* the package maintainer, and I know
what I want, I just don't know how Elpa interacts with Makefiles...

> Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
> gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
> “Wisdom begins in wonder.” --Socrates
> ((λ (x) (x x)) (λ (x) (x x)))
> “Life has become immeasurably better since I have been forced to stop
> taking it seriously.” --Thompson
>
>
> On Fri, Jul 11, 2014 at 10:26 PM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>> I'm slowly working on a getting a package Elpa-ready, and have just a
>> few more questions. One is the role of a Makefile.
>>
>> The only targets I really need are compilation, autoloads, and texinfo.
>> My understanding is that Elpa deployment will do all these things for me
>> (the last dependent on the presence of "<package>.texi" and "dir"
>> files). I don't need a Makefile for that.
>>
>> But I would like to also make the package installable straight from
>> github or other locations, in which case a Makefile will still be
>> necessary.
>>
>> In the Elpa repo I've seen packages with Makefiles, with no Makefiles,
>> and even with Makefiles that contain an "elpa" target. My question is,
>> will Elpa deployment honor an existing Makefile (in which case, which
>> targets are used?), ignore it, or conflict -- ie I should .elpaignore it
>> or something.
>>
>> Thanks!
>> E
>>
>>

Re: Elpa packages and Makefiles

[Stefan Monnier]

> will Elpa deployment honor an existing Makefile (in which case, which
> targets are used?), ignore it, or conflict -- ie I should .elpaignore it
> or something.

package.el currently just ignores the Makefile.
It also ignores the .texi files, by the way (sadly).


        Stefan

Re: Elpa packages and Makefiles

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > will Elpa deployment honor an existing Makefile (in which case, which
> > targets are used?), ignore it, or conflict -- ie I should .elpaignore it
> > or something.
>
> package.el currently just ignores the Makefile.
> It also ignores the .texi files, by the way (sadly).

AFAIK Melpa doesn't ignore these OTOH.  Don't know any details, but
since Melpa builds the packages itself on their server, they can handle
such things to some degree.

Re: Elpa packages and Makefiles

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> will Elpa deployment honor an existing Makefile (in which case, which
>> targets are used?), ignore it, or conflict -- ie I should .elpaignore it
>> or something.
>
> package.el currently just ignores the Makefile.
> It also ignores the .texi files, by the way (sadly).

Ah, that'll be why a few packages had their own "elpa" make target.
Okay -- good to know either way. Thanks!

Re: Elpa packages and Makefiles

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> will Elpa deployment honor an existing Makefile (in which case, which
>> targets are used?), ignore it, or conflict -- ie I should .elpaignore it
>> or something.
>
> package.el currently just ignores the Makefile.
> It also ignores the .texi files, by the way (sadly).

Okay I'm finally actually getting around to this, playing with a local
deployment to see how it works, and still have a few questions (just one
for now).

I've got this package in Github as well, so I'm leaving it there, and
moving local development to a subtree in elpa/packages.

I started out with putting all the lisp files under a lisp/ directory in
the main package directory (for reasons that now escape me). That
includes the main PACKAGE.el entry-point file. I'd prefer not to mess
with this, for the sake of existing users. Is there any sort of crutch I
can use to both allow Elpa to create its top-level PACKAGE-pkg.el file
(and put the lisp/ directory on the load path), and also not disturb
users who are running from Github and have manually put lisp/ into their
load path?

Perhaps, if the "crutch" is simple, I could put it in a separate "elpa"
branch that gets rebased on top of master, then push master to Github,
and elpa to Elpa?

Thanks,
Eric

Re: Elpa packages and Makefiles

[Stefan Monnier]

> I started out with putting all the lisp files under a lisp/ directory in
> the main package directory (for reasons that now escape me). That

GNU ELPA currently will ignore all .el files in subdirectories.
Just move your files out of the `lisp' dir once and for all.
You can add a `lisp' symlink (via "ln -s . lisp") for backward
compatibility if you want, but it's probably not worth the trouble.


        Stefan

Re: Elpa packages and Makefiles

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 01 Oct 2014 09:29:39 -0400
> 
> You can add a `lisp' symlink (via "ln -s . lisp")

That might not work on Windows.

Re: Elpa packages and Makefiles

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I started out with putting all the lisp files under a lisp/ directory in
>> the main package directory (for reasons that now escape me). That
>
> GNU ELPA currently will ignore all .el files in subdirectories.
> Just move your files out of the `lisp' dir once and for all.
> You can add a `lisp' symlink (via "ln -s . lisp") for backward
> compatibility if you want, but it's probably not worth the trouble.

Okay! That will certainly simplify things from here on out.

Thanks,
Eric

Re: Elpa packages and Makefiles

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I started out with putting all the lisp files under a lisp/ directory in
>> the main package directory (for reasons that now escape me). That
>
> GNU ELPA currently will ignore all .el files in subdirectories.
> Just move your files out of the `lisp' dir once and for all.
> You can add a `lisp' symlink (via "ln -s . lisp") for backward
> compatibility if you want, but it's probably not worth the trouble.

Last question! (I hope.)

If I specify an Elpa package as a :subtree, is this a subtree in the
sense of the actual "git subtree" command, or is this just a subtree
merge?

After I've added my Github upstream as a remote in elpa, and fetched its
branches locally, am I running this:

git subtree add --prefix packages/gnorb gnorb-remote master --squash

or this:

git checkout -b gnorb-branch gnorb-remote/master
git read-tree --prefix=packages/gnorb -u gnorb-branch

Time spent googling "git subtree" indicated that those were the two
likely possibilities.

Thanks for your patience, and hopefully I can give a little something
back, with a documentation patch for those of us who don't know git all
that well.

Eric

Re: Elpa packages and Makefiles

[Stefan Monnier]

> If I specify an Elpa package as a :subtree, is this a subtree in the
> sense of the actual "git subtree" command, or is this just a subtree
> merge?

:subtree means that the package is kept in the "master" branch of
elpa.git, in a subdirectory of `packages'.  And if there is a need to
merge from some external VCS, then the merge is typically done by
a "subtree merge".

> git subtree add --prefix packages/gnorb gnorb-remote master --squash

> or this:

> git checkout -b gnorb-branch gnorb-remote/master
> git read-tree --prefix=packages/gnorb -u gnorb-branch

I'm sorry, but I don't spend enough time with Git to know the difference
between these.  The way I do it, usually is by "git merge" which
sometimes doesn't put things at the right place (when it's the initial
importation of the package), so I then clean things up by hand.
The reason I prefer doing that is because I think I know what "git
merge" does, whereas I have difficulty understanding what "git
read-tree" or "git subtree" does.


        Stefan

Re: Elpa packages and Makefiles

[Ted Zlatanov]

On Wed, 08 Oct 2014 14:31:21 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The reason I prefer doing that is because I think I know what "git
SM> merge" does, whereas I have difficulty understanding what "git
SM> read-tree" or "git subtree" does.

`git subtree' is nice when you want subsequent resyncs of the same tree.

It can maintain a bijective commit ID mapping between the source repo
and the destination repo.

Ted

Re: Elpa packages and Makefiles

[Stefan Monnier]

SM> The reason I prefer doing that is because I think I know what "git
SM> merge" does, whereas I have difficulty understanding what "git
SM> read-tree" or "git subtree" does.
> `git subtree' is nice when you want subsequent resyncs of the same tree.
> It can maintain a bijective commit ID mapping between the source repo
> and the destination repo.

Subtree merges work fine as well for subsequent resyncs of the same
tree, and they don't need to maintain a bijective mapping between the
two (because this mapping is the identity mapping).


        Stefan

Re: Elpa packages and Makefiles

[Ted Zlatanov]

On Thu, 09 Oct 2014 10:40:09 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The reason I prefer doing that is because I think I know what "git
SM> merge" does, whereas I have difficulty understanding what "git
SM> read-tree" or "git subtree" does.
>> `git subtree' is nice when you want subsequent resyncs of the same tree.
>> It can maintain a bijective commit ID mapping between the source repo
>> and the destination repo.

SM> Subtree merges work fine as well for subsequent resyncs of the same
SM> tree, and they don't need to maintain a bijective mapping between the
SM> two (because this mapping is the identity mapping).

A merge is not the same thing as a bijective `git subtree' mapping which
can map paths for each commit. In the ELPA case at least, you're better
off your way. I was just trying to explain what that tool does because
it's been useful to me in the past.

Ted