Re: [CEDET-devel] Some thoughts about new EDE project types & related stuff

[Eric M. L. <er...@si...>]

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

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.

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.

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

Alternatively, there is the EDE project cache of known projects.  That 
is another way to track projects that have been opened before.

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 think we may need to just get a consistent lingo, and then the 
solution will be easier to agree upon. ;)

Thanks
Eric

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
> directory.
>
> 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
> http://alexott.net/
> 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
> http://p.sf.net/sfu/logmein_12329d2d
>
>
>
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel