Thread: [CEDET-devel] Some thoughts about new EDE project types & related stuff
Brought to you by:
zappo
From: Alex O. <al...@gm...> - 2012-12-26 12:42:25
|
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 targetsslot? 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 |
From: Eric M. L. <er...@si...> - 2013-01-04 03:23:58
|
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 |
From: Tomasz G. <to...@wp...> - 2013-01-05 23:25:22
|
"Eric M. Ludlam" <er...@si...> 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 > instead. 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 > projects. 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 configuration. > 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. Thanks Tomasz > 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 > > ------------------------------------------------------------------------------ > 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: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > > -- Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-15 02:17:47
|
On 01/05/2013 06:25 PM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<er...@si...> 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 >> instead. > > 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 >> projects. > > Can you point to some resources about this EDE security feature or > explain what it is? http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00387.html >> 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 > configuration. 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 removed. 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 re-open. 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 file also. 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 configuration. 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 different choices. In retrospect, I think android should probably move to be more like the arduino environment though. Eric |