"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.
> 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?
> 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
> 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.
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.
> I think we may need to just get a consistent lingo, and then the
> solution will be easier to agree upon. ;)
> On 12/26/2012 07:42 AM, Alex Ott wrote:
>> Hi all
>> I thought about extending EDE to support more project types - some work
>> was already started for JVM-based projects, but I found that we may need
>> to slightly change existing projects & maybe organize additional
>> hierarchy of projects.
>> Many build tools are using single project file that is always located in
>> the top of hierarchy - right now this are Maven, Ant, Clojure's
>> Leiningen, Erlang's Rebar, Scala's SBT. Some of these project types are
>> almost completely self-contained (maven, lein, sbt?, rebar), so we can
>> extract all necessary information (list of goals, source directories,
>> etc) from them, while some, like Ant, requires that we provided
>> additional information (list of directories with source code, classpath,
>> etc.) when creating EDE project.
>> Most of single root project types have different goals (in maven's
>> terminology) - targets that user can execute staying in top-level
>> directory, and configurations (for example, Maven's profiles) that
>> affect build process. But there is a difference between goals & EDE
>> targets - EDE targets always are bound to directory, while targets for
>> single root projects should be bound to different goals/commands defined
>> for given project, and these targets are always executed from top level
>> Right now we have hierarchy of classes, derived from |jvm-base| class,
>> but this class has several slots that could be useful for all *single
>> root* projects, not only for JVM-based (for example, Erlang's Rebar, and
>> maybe more). This are following slots:
>> * |file-mod-time| project file modification date (float). It's
>> useful to track also modifications in project file, as list of
>> dependencies (classpath), or other information could be changed;
>> * |current-target| - command (target) that is executed in the root
>> of the project. I want to allow user to switch between available
>> targets (list of targets could be dynamic, depending on project's
>> type), but right now not yet sure how it's better to make this –
>> add drop-down menu like is done for EDE configurations?
>> * |target-options| - additional options that are passed to command
>> (customizable by user)
>> * |existing-targets| - list of existed targets for given project. It
>> could be *static*, like for Rebar, or could by *dynamic* like for
>> Ant & Maven. Maybe this slot isn't necessary, if we could reuse
>> existing |targets| slot?
>> Some of these options, like |file-mod-time| could be put into
>> |ede-project|, but I'm thinking about adding new base class, like
>> |single-root-project|, inherited from |ede-project| and storing targets
>> information (or it's better to put everything into |ede-project|?). I'm
>> also not sure - should we store all these slots in the cache, or we can
>> extract all necessary information on first use.
>> What do you think about this? For me the most important are opinions
>> about maintaining targets & how it's better to organize switching
>> between targets.
>> With best wishes, Alex Ott
>> Twitter: alexott_en (English), alexott (Russian)
>> Skype: alex.ott
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> Cedet-devel mailing list
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> Cedet-devel mailing list