[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: running EDE from a file that is not under a project root dir
From: |
Dmitry Gutov |
Subject: |
Re: running EDE from a file that is not under a project root dir |
Date: |
Fri, 7 Aug 2015 00:45:08 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 |
On 08/06/2015 05:39 PM, Stephen Leake wrote:
How so? As long as your project-find-functions element knows which
variable to look up, you should be all set.
How would it know that?
Suppose I have a gpr project backend for AdaCore gprbuild projects, and
a gradle backend for Android gradle projects.
I was assuming your project backends would share a codebase. But if they
don't, they'll need to depend on a third package (which can be very small).
There are corresponding global variables; gpr-global-project,
gradle-global-project, each with a project-find function.
The third package would contain: variable global-project-current,
function global-project-visit, function global-project-try-it.
global-project-set will be called from gpr and gradle upon visiting a
project, and will set global-project-current to the project passed in to
it. global-project-try-it will be added to project-find-functions
(probably as soon as global-project is loaded), and will use
global-project-current. The variable could as well be made private.
I'm proposing to fix this by having one global variable with one
find-function.
So I take it you're asking the above global-project to be moved to the
core. I'm hesitant, but it's better than what I originally understood
your request to be (add the variable, and make it higher priority than
project-find-functions).
I wonder if the concept of the global project will be very popular.
You seem to have some other solution in mind; what would it be?
Hmm. Perhaps the "select project" function could change
project-find-functions as well, using delq and add-to-list. But that
messes with the order of the list, which the user may have carefully
set. For example, I currently have it set to '(project-try-ede
project-find-prj-root project-explicit-prj).
If you're willing to sacrifice the "order of the list carefully set by
the user", the delq + add-to-list (or add-hook; this should be carefully
considered) solution can be pretty elegant. It's not what I had in mind,
but I like it.
- running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/04
- Re: running EDE from a file that is not under a project root dir, Dmitry Gutov, 2015/08/04
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/05
- Re: running EDE from a file that is not under a project root dir, Dmitry Gutov, 2015/08/05
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/06
- Re: running EDE from a file that is not under a project root dir, Dmitry Gutov, 2015/08/06
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/06
- Re: running EDE from a file that is not under a project root dir,
Dmitry Gutov <=
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/07
Re: running EDE from a file that is not under a project root dir, Eric Ludlam, 2015/08/04
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/05
- Re: running EDE from a file that is not under a project root dir, Eric Ludlam, 2015/08/05
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/06
- Re: running EDE from a file that is not under a project root dir, David Engster, 2015/08/06
- Re: running EDE from a file that is not under a project root dir, Stephen Leake, 2015/08/06
- Re: running EDE from a file that is not under a project root dir, David Engster, 2015/08/07