Thread: [CEDET-devel] Help needed testing EDE branch
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2014-06-14 01:57:32
|
Hi all, I've been working on a task branch for EDE for a while, and I'd like to check it into Trunk, but I'd also like to make sure I don't break anyone's workflow, so I need your help! This code change is a result of a suggestion from emacs-devel mailing list to use 'locate-dominating-file' as a way of solving a long-standing problem in EDE where some types of projects won't be detected unless you first visit a file in the root of the project. There is also a huge new unit testing suite for all the known projects to make sure they correctly detect, reset, and rescan. This has resulted in a LOT of bug fixes! The new project detector is so good, I was able to delete a bunch of code out of all the different project classes, making it much easier to create a new project. Nice! Next, there are five NEW generic project types! They are all Version Control based, and will detect git, bzr, hg, svn, and cvs. As generic projects, they are detect LAST after all specific project types. To take advantage of the features, you can use 'customize-project' and set up your C++ headers, or java classpath. I hope this change makes it possible to drop support for cpp-root and java-root style projects in the future by finding and fixing deficiencies in the generic project type. So, how can you help? If you are using CEDET from the BZR repository, and use EDE as part of your configuration, please pull down the "ede-ldf" branch, where "ldf" stands for "locate dominating file". To grab a copy, you can do this: bzr checkout bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/ede-ldf cedet and the typical "make" to get it going. Since it would be great to enable generic projects now that they are more reliable, please also add: (ede-enable-generic-projects) to your .emacs file, and see if you detect any problems. Thats it! After using it for a little while, I'd greatly appreciate some replies on this thread stating what projects you typically use, and if you ran into any problems. Thanks! Eric |
From: Lluís <xs...@gm...> - 2014-06-20 15:18:43
|
Eric M Ludlam writes: [...] > After using it for a little while, I'd greatly appreciate some replies > on this thread stating what projects you typically use, and if you ran > into any problems. Hi! I just tested opening a file of a copy that I have of the Linux kernel, and it is detected as a "ede-generic-makefile-project", instead of the linux-specific project type (which basically sets the include directories). Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Eric M. L. <er...@si...> - 2014-06-21 12:52:42
|
On 06/20/2014 11:18 AM, Lluís wrote: > Eric M Ludlam writes: > [...] >> After using it for a little while, I'd greatly appreciate some replies >> on this thread stating what projects you typically use, and if you ran >> into any problems. > > Hi! I just tested opening a file of a copy that I have of the Linux kernel, and > it is detected as a "ede-generic-makefile-project", instead of the > linux-specific project type (which basically sets the include directories). Thanks Lluis, With this hint I was able to create a unit test that replicated the problem. Eric |
From: Lluís <xs...@gm...> - 2014-06-22 19:30:21
|
Eric M Ludlam writes: > On 06/20/2014 11:18 AM, Lluís wrote: >> Eric M Ludlam writes: >> [...] >>> After using it for a little while, I'd greatly appreciate some replies >>> on this thread stating what projects you typically use, and if you ran >>> into any problems. >> >> Hi! I just tested opening a file of a copy that I have of the Linux kernel, and >> it is detected as a "ede-generic-makefile-project", instead of the >> linux-specific project type (which basically sets the include directories). > I have updated tests for the linux case to match what you described, and fixed > the problem in the project detector. Thanks! This was a broad missing case for > the wide list of possible projects I missed when crafting my test suite. > There are many projects I do not use in EDE and for which I merely simulated in > the EDE test suites. I greatly appreciate folks giving this task branch a try! > I merged from trunk and pushed that and the new fixes back to the ede-ldf > branch. That worked like a charm, thanks. I also tried to run "customize-project" on a linux project, and it looks like no file is saved with the project customizations. I guess that's still not possible (to somehow "overlay" local customizations on auto-detected projects). Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Lluís <xs...@gm...> - 2014-06-22 19:47:11
|
Lluís writes: > Eric M Ludlam writes: >> On 06/20/2014 11:18 AM, Lluís wrote: >>> Eric M Ludlam writes: >>> [...] >>>> After using it for a little while, I'd greatly appreciate some replies >>>> on this thread stating what projects you typically use, and if you ran >>>> into any problems. >>> >>> Hi! I just tested opening a file of a copy that I have of the Linux kernel, and >>> it is detected as a "ede-generic-makefile-project", instead of the >>> linux-specific project type (which basically sets the include directories). >> I have updated tests for the linux case to match what you described, and fixed >> the problem in the project detector. Thanks! This was a broad missing case for >> the wide list of possible projects I missed when crafting my test suite. >> There are many projects I do not use in EDE and for which I merely simulated in >> the EDE test suites. I greatly appreciate folks giving this task branch a try! >> I merged from trunk and pushed that and the new fixes back to the ede-ldf >> branch. > That worked like a charm, thanks. I also tried to run "customize-project" on a > linux project, and it looks like no file is saved with the project > customizations. I guess that's still not possible (to somehow "overlay" local > customizations on auto-detected projects). I don't know if this is exclusive to this branch, but hitting the "Commands" tab in the customization buffer of this project ("ede-toplevel"): [object ede-generic-makefile-project "ede-generic-makefile-project" nil "dpa.run" "1.0" "~/Projects/dpa/dpa.run/" 7979453 "/home/lluis/Projects/dpa/dpa.run/Makefile" nil nil ([object ede-generic-target-misc "ede-generic-target-misc" nil "Misc" "/home/lluis/Projects/dpa/dpa.run/" nil nil]) unbound unbound "" "" "" "" "" "" ("debug" "release") "debug" nil [object ede-generic-config "Configuration" "/home/lluis/Projects/dpa/dpa.run/EDEConfig.el" #0 "make -k" "gdb " nil nil nil nil nil]] Results in an error when building the widget for "Run-Command". It turns out that the widget's ":value" is nil, so "(insert value)" fails. Later on, hitting "Accept" or "Apply" also fails, but that could be because of the first failure. Thanks, Lluis |
From: Eric M. L. <er...@si...> - 2014-06-23 23:32:13
|
On 06/22/2014 03:47 PM, Lluís wrote: > Lluís writes: > I don't know if this is exclusive to this branch, but hitting the "Commands" tab > in the customization buffer of this project ("ede-toplevel"): > > [object ede-generic-makefile-project "ede-generic-makefile-project" nil "dpa.run" "1.0" "~/Projects/dpa/dpa.run/" 7979453 "/home/lluis/Projects/dpa/dpa.run/Makefile" nil nil > ([object ede-generic-target-misc "ede-generic-target-misc" nil "Misc" "/home/lluis/Projects/dpa/dpa.run/" nil nil]) > unbound unbound "" "" "" "" "" "" > ("debug" "release") > "debug" nil > [object ede-generic-config "Configuration" "/home/lluis/Projects/dpa/dpa.run/EDEConfig.el" #0 "make -k" "gdb " nil nil nil nil nil]] > > Results in an error when building the widget for "Run-Command". It turns out > that the widget's ":value" is nil, so "(insert value)" fails. Hi Lluis, This was easy to fix in the class to make the :type and :custom types match. Thanks! I've pushed a new version so you can try it out. Eric |
From: Lluís <xs...@gm...> - 2014-06-25 20:43:49
|
Eric M Ludlam writes: > On 06/22/2014 03:30 PM, Lluís wrote: >> I also tried to run "customize-project" on a >> linux project, and it looks like no file is saved with the project >> customizations. I guess that's still not possible (to somehow "overlay" local >> customizations on auto-detected projects). > Hi Lluis, > There are definitely two camps on these project types. Some generate > your build system have save files to remember your configuration (such > as the the 'proj' type that supports creating both Makefiles and > Automake files. > The other types such as Linux, Emacs, cpp-root, arduino, and the other > automake project type which all detect existing projects, and if you > want to customize them, you need to edit some file related to that > project which Emacs would read in later. That makes all the sense in the world. > The generic project is different in that it just tries to find some of > your code in project form, and then has a configuration that sits on top > that saves itself between sessions. This system is nice in that the > code to make the project is simple, but you still get at the key pieces > needed for Semantic smart completion parsing, etc. > I think your observation is that some of the project types such as Linux > and Emacs don't have enough automatically configured such that you want > to add some extra on top and save it away. Perhaps the right thing is > to update 'linux' as a subclass of 'generic' but with some of the extra > goodness from ede/linux kept around for pre-configuring the system. I don't have any specific use-case. I was just wondering if it would be possible to, for example, customize something like cpp-root's spp-table in ede-linux-project, or, for example, set some project-local variables or the build command. In fact, I think that saving the project-local variables across sessions would be the most useful feature at this point. To me it makes sense to implement this functionality in EDE, but many other tools try to do the same, and emacs also has the directory-local variables. I know it would be a huge effort, but do you think it would make sense to refactor the project class hierarchy? For example: * There could be the current ede-project as a base. * Per-language subclasses, (e.g., ede-lang-c, ede-lang-c++, ede-lang-java, etc.), which only care about language-specific things like include directories and preprocessor macros. * Per "project" subclasses, like ede-proj-linux inheriting from ede-lang-c and automatically setting some of its values like include directories. The ede-generic-project could be refactored as inheriting from some "sane" set of per-language project types (maybe from all of them?). Honestly, I don't know how the automake, make, etc. project types would fit in this scheme. Now that I think about it, the project defines two things, the per-language resources (what I called per-language project classes), and the per-build-system logic (like an automake project type; linux could be in this category too). The latter could thus feed information to the former. Just thinking out loud. > As I don't use that project type, I'm uncertain if that makes sense, but > I could whip up a prototype if you think it would be useful. You could > probably simulate by just deleting ede/linux.el, rebuilding, and see > what happens when it instead finds your Linux project via the generic > Makefile project type. AFAIR, the ede-linux-project does two main things: * Perform project auto-detection using a project-specific method (by checking if a specific file exists with specific contents). * Setting the appropriate include paths for semantic and other tools (also taking into account that a separate build directory can contain part of the include paths). Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Eric M. L. <er...@si...> - 2014-06-27 01:47:35
|
On 06/25/2014 04:43 PM, Lluís wrote: > Eric M Ludlam writes: >> I think your observation is that some of the project types such as Linux >> and Emacs don't have enough automatically configured such that you want >> to add some extra on top and save it away. Perhaps the right thing is >> to update 'linux' as a subclass of 'generic' but with some of the extra >> goodness from ede/linux kept around for pre-configuring the system. > > I don't have any specific use-case. I was just wondering if it would be possible > to, for example, customize something like cpp-root's spp-table in > ede-linux-project, or, for example, set some project-local variables or the > build command. > > In fact, I think that saving the project-local variables across sessions would > be the most useful feature at this point. To me it makes sense to implement this > functionality in EDE, but many other tools try to do the same, and emacs also > has the directory-local variables. > > I know it would be a huge effort, but do you think it would make sense to > refactor the project class hierarchy? For example: > > * There could be the current ede-project as a base. > > * Per-language subclasses, (e.g., ede-lang-c, ede-lang-c++, ede-lang-java, > etc.), which only care about language-specific things like include > directories and preprocessor macros. I think that makes sense. While re-writing the detection of all these projects, I noticed there is replication between several projects for the different targets. The original design did not expect lots of very simplistic projects/target combinations. > * Per "project" subclasses, like ede-proj-linux inheriting from ede-lang-c and > automatically setting some of its values like include directories. > > The ede-generic-project could be refactored as inheriting from some "sane" set > of per-language project types (maybe from all of them?). There are two useful pieces to 'generic', one of which is the customizable configuration, and the other is an easy way to add new detection schemes. Perhaps the configuration could be made as a base that other projects could pull in as needed. I think this is an interesting set of ideas. Something to tackle when we finish validating the current major change regarding the project detection. Eric |
From: Lluís <xs...@gm...> - 2014-06-26 16:16:08
|
Daniel Colascione writes: > On 06/25/2014 01:43 PM, Lluís wrote: >> Eric M Ludlam writes: >> >>> On 06/22/2014 03:30 PM, Lluís wrote: >>>> I also tried to run "customize-project" on a >>>> linux project, and it looks like no file is saved with the project >>>> customizations. I guess that's still not possible (to somehow "overlay" local >>>> customizations on auto-detected projects). >> >>> Hi Lluis, >> >>> There are definitely two camps on these project types. Some generate >>> your build system have save files to remember your configuration (such >>> as the the 'proj' type that supports creating both Makefiles and >>> Automake files. >> >>> The other types such as Linux, Emacs, cpp-root, arduino, and the other >>> automake project type which all detect existing projects, and if you >>> want to customize them, you need to edit some file related to that >>> project which Emacs would read in later. >> >> That makes all the sense in the world. >> >> >>> The generic project is different in that it just tries to find some of >>> your code in project form, and then has a configuration that sits on top >>> that saves itself between sessions. This system is nice in that the >>> code to make the project is simple, but you still get at the key pieces >>> needed for Semantic smart completion parsing, etc. >> >>> I think your observation is that some of the project types such as Linux >>> and Emacs don't have enough automatically configured such that you want >>> to add some extra on top and save it away. Perhaps the right thing is >>> to update 'linux' as a subclass of 'generic' but with some of the extra >>> goodness from ede/linux kept around for pre-configuring the system. >> >> I don't have any specific use-case. I was just wondering if it would be possible >> to, for example, customize something like cpp-root's spp-table in >> ede-linux-project, or, for example, set some project-local variables or the >> build command. >> >> In fact, I think that saving the project-local variables across sessions would >> be the most useful feature at this point. To me it makes sense to implement this >> functionality in EDE, but many other tools try to do the same, and emacs also >> has the directory-local variables. >> >> I know it would be a huge effort, but do you think it would make sense to >> refactor the project class hierarchy? For example: >> >> * There could be the current ede-project as a base. >> >> * Per-language subclasses, (e.g., ede-lang-c, ede-lang-c++, ede-lang-java, >> etc.), which only care about language-specific things like include >> directories and preprocessor macros. > I don't think language should have anything to do with the project > system. Plenty of projects (like Emacs!) are written in a mixture of > languages. Projects should opportunistically define facilities that > language modes can use, e.g., header file disambiguation, but there > should be no such thing as a "C++ project". Right. Why I meant is that projects can then use multiple-inheritance to enable the language-specific features of all the languages in the project. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Eric M. L. <er...@si...> - 2014-06-22 00:54:22
|
On 06/20/2014 11:18 AM, Lluís wrote: > Eric M Ludlam writes: > [...] >> After using it for a little while, I'd greatly appreciate some replies >> on this thread stating what projects you typically use, and if you ran >> into any problems. > > Hi! I just tested opening a file of a copy that I have of the Linux kernel, and > it is detected as a "ede-generic-makefile-project", instead of the > linux-specific project type (which basically sets the include directories). I have updated tests for the linux case to match what you described, and fixed the problem in the project detector. Thanks! This was a broad missing case for the wide list of possible projects I missed when crafting my test suite. There are many projects I do not use in EDE and for which I merely simulated in the EDE test suites. I greatly appreciate folks giving this task branch a try! I merged from trunk and pushed that and the new fixes back to the ede-ldf branch. Thanks! Eric |
From: Eric M. L. <er...@si...> - 2014-06-23 23:42:57
|
On 06/22/2014 03:30 PM, Lluís wrote: > I also tried to run "customize-project" on a > linux project, and it looks like no file is saved with the project > customizations. I guess that's still not possible (to somehow "overlay" local > customizations on auto-detected projects). Hi Lluis, There are definitely two camps on these project types. Some generate your build system have save files to remember your configuration (such as the the 'proj' type that supports creating both Makefiles and Automake files. The other types such as Linux, Emacs, cpp-root, arduino, and the other automake project type which all detect existing projects, and if you want to customize them, you need to edit some file related to that project which Emacs would read in later. The generic project is different in that it just tries to find some of your code in project form, and then has a configuration that sits on top that saves itself between sessions. This system is nice in that the code to make the project is simple, but you still get at the key pieces needed for Semantic smart completion parsing, etc. I think your observation is that some of the project types such as Linux and Emacs don't have enough automatically configured such that you want to add some extra on top and save it away. Perhaps the right thing is to update 'linux' as a subclass of 'generic' but with some of the extra goodness from ede/linux kept around for pre-configuring the system. As I don't use that project type, I'm uncertain if that makes sense, but I could whip up a prototype if you think it would be useful. You could probably simulate by just deleting ede/linux.el, rebuilding, and see what happens when it instead finds your Linux project via the generic Makefile project type. Eric |
From: Daniel C. <da...@da...> - 2014-06-25 21:28:13
Attachments:
signature.asc
|
On 06/25/2014 01:43 PM, Lluís wrote: > Eric M Ludlam writes: > >> On 06/22/2014 03:30 PM, Lluís wrote: >>> I also tried to run "customize-project" on a >>> linux project, and it looks like no file is saved with the project >>> customizations. I guess that's still not possible (to somehow "overlay" local >>> customizations on auto-detected projects). > >> Hi Lluis, > >> There are definitely two camps on these project types. Some generate >> your build system have save files to remember your configuration (such >> as the the 'proj' type that supports creating both Makefiles and >> Automake files. > >> The other types such as Linux, Emacs, cpp-root, arduino, and the other >> automake project type which all detect existing projects, and if you >> want to customize them, you need to edit some file related to that >> project which Emacs would read in later. > > That makes all the sense in the world. > > >> The generic project is different in that it just tries to find some of >> your code in project form, and then has a configuration that sits on top >> that saves itself between sessions. This system is nice in that the >> code to make the project is simple, but you still get at the key pieces >> needed for Semantic smart completion parsing, etc. > >> I think your observation is that some of the project types such as Linux >> and Emacs don't have enough automatically configured such that you want >> to add some extra on top and save it away. Perhaps the right thing is >> to update 'linux' as a subclass of 'generic' but with some of the extra >> goodness from ede/linux kept around for pre-configuring the system. > > I don't have any specific use-case. I was just wondering if it would be possible > to, for example, customize something like cpp-root's spp-table in > ede-linux-project, or, for example, set some project-local variables or the > build command. > > In fact, I think that saving the project-local variables across sessions would > be the most useful feature at this point. To me it makes sense to implement this > functionality in EDE, but many other tools try to do the same, and emacs also > has the directory-local variables. > > I know it would be a huge effort, but do you think it would make sense to > refactor the project class hierarchy? For example: > > * There could be the current ede-project as a base. > > * Per-language subclasses, (e.g., ede-lang-c, ede-lang-c++, ede-lang-java, > etc.), which only care about language-specific things like include > directories and preprocessor macros. I don't think language should have anything to do with the project system. Plenty of projects (like Emacs!) are written in a mixture of languages. Projects should opportunistically define facilities that language modes can use, e.g., header file disambiguation, but there should be no such thing as a "C++ project". |
From: Daniel C. <da...@da...> - 2014-06-26 16:28:19
Attachments:
signature.asc
|
On 06/26/2014 09:15 AM, Lluís wrote: > Right. Why I meant is that projects can then use multiple-inheritance to enable > the language-specific features of all the languages in the project. That still doesn't make any sense: why derive support for some languages are not others? All projects deserve support for all languages, so language support doesn't even belong in the same type hierarchy as project types. |
From: Lluís <xs...@gm...> - 2014-06-26 19:01:14
|
Daniel Colascione writes: > On 06/26/2014 09:15 AM, Lluís wrote: >> Right. Why I meant is that projects can then use multiple-inheritance to enable >> the language-specific features of all the languages in the project. > That still doesn't make any sense: why derive support for some languages > are not others? All projects deserve support for all languages, so > language support doesn't even belong in the same type hierarchy as > project types. Exactly. That's why I said (or at least I thought about it, don't remember if I said it in the mail), that maybe it would make more sense to extract the language support out of the project classes, and let projects use support for whatever language they need (e.g., linux needs support for very specific languages, automake projects could try to detect which languages must be supported by looking at configure.in, generic projects could add support for all languages, etc.). Of course, that would make sense only if there is some language-specific logic in EDE (besides setting variables like the include paths), which I don't know. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |