On 01/05/2013 06:25 PM, Tomasz Gajewski wrote:
> "Eric M. Ludlam"<eric@...> writes:
>> I've been wondering how best to reply to this nice email for a few
>> days now. The best I can come up with is a shrug and "Yup, sounds
>> like a useful and overdue endeavor."
>> So instead of providing useful feedback up front, I'll tell a story
> Thank you for this. My comments in text.
>> I started EDE because I'd just finished writing project-am.el and
>> realized that I still was writing piles of small Makefiles and I could
>> probably abstract things. I went into it with the idea of doing plain
>> Makefiles for basic projects, and started abstracting away. I really
>> wanted a system that magically identified your projects and loaded
>> them for you, as I found Vis studio forcing you to load your projects
>> was terribly medieval.
> This is only one side of story. You seem to typically start with opening
> a file and want to automatically get some settings automatically for
> this file - settings in some broad sense.
> The other useful case is to open a project (which is easy to find) and
> later browse or look for resources, e.g. files, methods, classes,
> etc. In such cases you don't start with file.
Yes, there are many useful things you can do with projects. I happened
to just start with one of them.
>> As far as I can tell, almost no-one ever used that stuff for what it
>> was intended, and I stopped writing so many little projects, so I
>> didn't use it either, except for managing the CEDET projects.
>> Projects, however, are a super-useful concept Semantic really needed
>> to understand to be useful, and there was no other way to do it, so
>> EDE started expanding, and what people really needed was a way to wrap
>> up other projects for Semantic, and please, EDE, leave me alone.
> No matter how many times I read it I can't figure out what you wanted to
> say :-). In the last part did you mean that people used ede only in a
> level that was required to have semantic working?
Yes, some folks only need EDE to wrap up a project in order to make
Semantic work. The "and please.." part was someone talking to EDE, but
I didn't have the right punctuation.
>> The pieces I've struggled with the most are the projects that have
>> some root anchor, and no indicators in the sub directories. I used to
>> have a tip of logic that would walk upwards to find such a file, but
>> that code killed our networked file systems where I work when you
>> loaded a file not in a project, so clearly that was a bad idea. I
>> opted to not worry about it, as the cpp-root project seemed to do a
>> good job for most cases, and was, sadly, medieval in the user's need
>> to predict what projects they wanted open.
>> Anyway, what this all means is that I think your enthusiasm to solve
>> some of these issues is both welcome, and as you suggest, we should
>> consider updates to the core to better enable these new build systems
>> into the fold. In particular, build systems that EDE doesn't
>> generate, but merely observes.
>> I also think it may be necessary to ask users to 'open' projects in
>> some directory, and move away from detection, because it has become
>> unreliable in the face of single-file in a tree detection. That would
>> also help the the new EDE security feature where it asks to load in
> Can you point to some resources about this EDE security feature or
> explain what it is?
>> Alternatively, there is the EDE project cache of known projects. That
>> is another way to track projects that have been opened before.
> Maybe some file or specific directory should be created in directories
> opened as projects. Project.ede file AFAIR used for one type of projects
> could be extended to contain information about different types of
> projects. This could help to autoload projects opened earlier and also
> to move a project to another place/machine and have it along with
Indeed. For a while there was the simple ede project
(ede-simple-project) which did that. It wasn't used, and some folks are
unwilling to use a project type that save a project file in the same
location as their source. Thus, ede-simple could also save in a ~/.ede
directory. Unfortunately, it just didn't work out, so was eventually
There is also ~/.projects.ede to track all projects you opened already.
This, I think, would be a handy concept to continue since it would
allow a nice dynamic menu full of recently opened projects you could
Lastly, ede-generic is very similar to what you describe. It will
identify some basic build systems, like Makefile, or SCons, and saves a
neighboring config file in EDEconfig.el. This system is super-easy to
expand, but it has trouble with projects with a single top-level config
As Alex pointed out though, many useful configuration settings already
exist in the build system. It is just a matter of extracting the data
from them, and extra Emacs specific settings may not be needed.
>> In your text below, you are interested in switching between 'targets',
>> and to me, it sounded like a 'configuration'. This seems like a
>> lingo-issue to me.
>> If you are visiting some file "foo.java", that will belong to a
>> target. As such, ede-compile-target should just do what you want.
>> Except that your target concept is more like 'debug', 'install',
>> 'upload', or something like that. That is more like a configuration.
>> If it is a mix, then maybe some other concept is needed. It is OK for
>> a file to belong to multiple targets, so maybe the regular 'compile
>> target' concept will continue to work.
> I don't think relation file->target is so simple. What if you have a
> header file opened. It can be required to recompile may
> targets (programs/libraries) after a change to a header file.
Indeed, this a where things break down with EDE's model.
> As about configuration vs. target I tend to think about configuration as
> a set of settings (environment, options) that specify how to build,
> e.g. target system, used compiler, compiling in debug or release
> mode. So 'debug' from your list would be a configuration for me. Rest
> from list are targets for me.
> Any target can be "executed" for any configuration.
Yes, but that isn't always useful. For the android project type, the
install on device target wasn't useful as a source code collection, so I
made it a configuration, even though from a build perspective, it was a
target. That way I could switch between different build modes easily.
For arduino, the configurations were handy, and uploading was more of a
specific action, so I made it a project specific option, instead of a
In a way, android and arduino had nearly the same thing going on, but
the way I tended to develop on those platforms was different, and I made
In retrospect, I think android should probably move to be more like the
arduino environment though.