Document how to create an .eproject file!

[Dave Abrahams]

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

[Anton Vasiljev]

+1

[deets]

+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.

[Jonathan Rockway]

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 :)

[Anton Vasiljev]

Any examples? :)

[David Creswick]

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"))

[Jonathan Rockway]

Looks pretty interesting, dcrewi.

Is this issue resolved or are there still questions?

[Phil Hagelberg]

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