Document how to create an .eproject file! #14

Open
dabrahams opened this Issue Feb 6, 2012 · 7 comments

Projects

None yet

6 participants

@dabrahams

You should start by documenting the /existence/ of .eproject files :-)

@antono
Contributor
antono commented May 26, 2012

+1

@deets
deets commented Aug 15, 2012

+1. And being able to save them would be great, too. I'm looking for a way to set build targets and other properties for projects on a per-working-copy base.

@jrockway
Owner
jrockway commented Oct 3, 2012

I'm not sure where the best place to put this would be.

While I figure that out... .eproject is just a list of :name value pairs, and (eproject-attribute :name) will evaluate to "value" in projects where the file exists. (Any lisp forms in the file must be "safe" as defined by "unsafep".) The existence of .eproject has the additional side effect of making a directory a project when it wouldn't otherwise qualify. That's about it :)

@antono
Contributor
antono commented Oct 12, 2012

Any examples? :)

@dcrewi
Contributor
dcrewi commented Jan 19, 2013

To define per-project tasks, @deets, cherry-pick dcrewi/eproject@266941f from my fork (or add the relevant bits to your .emacs). You can then add tasks by defining them in a .eproject. eproject reads that file even when a project type is detected, so you can augment the task list for a specific project directory while still having access to the tasks defined for that project type. Here is my current .eproject file for firefox builds inside a debian wheezy chroot:

:tasks '(("run" :shell "schroot -c wheezy -- env DISPLAY=:0 ./obj-i686-pc-linux-gnu/dist/bin/firefox -no-remote -P nightly")
         ("incremental-build" :shell "cd obj-i686-pc-linux-gnu && schroot -c wheezy -- nice -10 make -j2")
         ("build" :shell "schroot -c wheezy -- nice -10 ./mach build")
         ("clobber" :confirm :shell "schroot -c wheezy -- ./mach clobber"))
@jrockway
Owner
jrockway commented Feb 3, 2013

Looks pretty interesting, dcrewi.

Is this issue resolved or are there still questions?

@technomancy

How is this different from using .dir-locals.el, which is already in common usage and well-documented?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment