* Elpa packages and Makefiles
@ 2014-07-12 3:26 Eric Abrahamsen
2014-07-12 14:55 ` Grant Rettke
2014-07-18 16:23 ` Stefan Monnier
0 siblings, 2 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2014-07-12 3:26 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-12 3:26 Elpa packages and Makefiles Eric Abrahamsen
@ 2014-07-12 14:55 ` Grant Rettke
2014-07-13 1:39 ` Eric Abrahamsen
2014-07-18 16:23 ` Stefan Monnier
1 sibling, 1 reply; 15+ messages in thread
From: Grant Rettke @ 2014-07-12 14:55 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: Emacs Help
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
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-12 14:55 ` Grant Rettke
@ 2014-07-13 1:39 ` Eric Abrahamsen
0 siblings, 0 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2014-07-13 1:39 UTC (permalink / raw
To: help-gnu-emacs
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
>>
>>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-12 3:26 Elpa packages and Makefiles Eric Abrahamsen
2014-07-12 14:55 ` Grant Rettke
@ 2014-07-18 16:23 ` Stefan Monnier
2014-07-19 0:26 ` Michael Heerdegen
` (2 more replies)
1 sibling, 3 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-07-18 16:23 UTC (permalink / raw
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-18 16:23 ` Stefan Monnier
@ 2014-07-19 0:26 ` Michael Heerdegen
2014-07-19 1:24 ` Eric Abrahamsen
2014-10-01 10:11 ` Eric Abrahamsen
2 siblings, 0 replies; 15+ messages in thread
From: Michael Heerdegen @ 2014-07-19 0:26 UTC (permalink / raw
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-18 16:23 ` Stefan Monnier
2014-07-19 0:26 ` Michael Heerdegen
@ 2014-07-19 1:24 ` Eric Abrahamsen
2014-10-01 10:11 ` Eric Abrahamsen
2 siblings, 0 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2014-07-19 1:24 UTC (permalink / raw
To: help-gnu-emacs
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!
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-07-18 16:23 ` Stefan Monnier
2014-07-19 0:26 ` Michael Heerdegen
2014-07-19 1:24 ` Eric Abrahamsen
@ 2014-10-01 10:11 ` Eric Abrahamsen
2014-10-01 13:29 ` Stefan Monnier
2 siblings, 1 reply; 15+ messages in thread
From: Eric Abrahamsen @ 2014-10-01 10:11 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-01 10:11 ` Eric Abrahamsen
@ 2014-10-01 13:29 ` Stefan Monnier
2014-10-01 14:50 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-10-01 13:29 UTC (permalink / raw
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-01 13:29 ` Stefan Monnier
@ 2014-10-01 14:50 ` Eli Zaretskii
2014-10-01 17:06 ` Eric Abrahamsen
2014-10-08 3:32 ` Eric Abrahamsen
2 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2014-10-01 14:50 UTC (permalink / raw
To: Stefan Monnier; +Cc: help-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-01 13:29 ` Stefan Monnier
2014-10-01 14:50 ` Eli Zaretskii
@ 2014-10-01 17:06 ` Eric Abrahamsen
2014-10-08 3:32 ` Eric Abrahamsen
2 siblings, 0 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2014-10-01 17:06 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-01 13:29 ` Stefan Monnier
2014-10-01 14:50 ` Eli Zaretskii
2014-10-01 17:06 ` Eric Abrahamsen
@ 2014-10-08 3:32 ` Eric Abrahamsen
2014-10-08 18:31 ` Stefan Monnier
[not found] ` <mailman.10760.1412793114.1147.help-gnu-emacs@gnu.org>
2 siblings, 2 replies; 15+ messages in thread
From: Eric Abrahamsen @ 2014-10-08 3:32 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-08 3:32 ` Eric Abrahamsen
@ 2014-10-08 18:31 ` Stefan Monnier
[not found] ` <mailman.10760.1412793114.1147.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-10-08 18:31 UTC (permalink / raw
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
[not found] ` <mailman.10760.1412793114.1147.help-gnu-emacs@gnu.org>
@ 2014-10-09 13:24 ` Ted Zlatanov
2014-10-09 14:40 ` Stefan Monnier
[not found] ` <mailman.10797.1412865640.1147.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 15+ messages in thread
From: Ted Zlatanov @ 2014-10-09 13:24 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
2014-10-09 13:24 ` Ted Zlatanov
@ 2014-10-09 14:40 ` Stefan Monnier
[not found] ` <mailman.10797.1412865640.1147.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-10-09 14:40 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Elpa packages and Makefiles
[not found] ` <mailman.10797.1412865640.1147.help-gnu-emacs@gnu.org>
@ 2014-10-09 15:40 ` Ted Zlatanov
0 siblings, 0 replies; 15+ messages in thread
From: Ted Zlatanov @ 2014-10-09 15:40 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-10-09 15:40 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-12 3:26 Elpa packages and Makefiles Eric Abrahamsen
2014-07-12 14:55 ` Grant Rettke
2014-07-13 1:39 ` Eric Abrahamsen
2014-07-18 16:23 ` Stefan Monnier
2014-07-19 0:26 ` Michael Heerdegen
2014-07-19 1:24 ` Eric Abrahamsen
2014-10-01 10:11 ` Eric Abrahamsen
2014-10-01 13:29 ` Stefan Monnier
2014-10-01 14:50 ` Eli Zaretskii
2014-10-01 17:06 ` Eric Abrahamsen
2014-10-08 3:32 ` Eric Abrahamsen
2014-10-08 18:31 ` Stefan Monnier
[not found] ` <mailman.10760.1412793114.1147.help-gnu-emacs@gnu.org>
2014-10-09 13:24 ` Ted Zlatanov
2014-10-09 14:40 ` Stefan Monnier
[not found] ` <mailman.10797.1412865640.1147.help-gnu-emacs@gnu.org>
2014-10-09 15:40 ` Ted Zlatanov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.