I appear to have replied to your other email too soon. ;)
I'm glad you have a working solution. ede-cpp-root is fine to use, it
just happens to have C++ specific features. If the include paths work
for java too, so much the better.
Eric
On 07/29/2010 06:33 PM, David Ventimiglia wrote:
> Hi,
>
> For Java support, I'm trying a different tact (perhaps one you
> recommended in the past): using ede-cpp-root-project, since it has the
> desired property that just one file at the "root" of a project can
> "anchor" that root. I added this to my .emacs file:
>
> (require 'cedet)
> (global-ede-mode 1)
> (semantic-load-enable-excessive-code-helpers)
> (require 'ede-locate)
> (semanticdb-enable-gnu-global-databases 'java-mode)
> (semanticdb-enable-gnu-global-databases 'jde-mode)
> (ede-cpp-root-project "<shortname>"
> :name "<longname>"
> :file "<root-dir>/<app-name>.iml"
> :include-path '("/<module1>/src"
> "/<module2>/src"
> ...)
> :header-match-regexp "\\.java\\|\\<\\w+$")
>
> <app-name>.iml is just a project file used by the IntelliJ editor, which
> is popular where I work. It's just a handy "anchor file". Using
> ede-cpp-root-project is in lieu of any sort of "ede-ant" style project.
> While my project does use Ant as a build tool, the EDE features related
> to compilation/building/debugging are not the ones I desire, but rather
> the features that support semantic, semanticb, semantic-ia, and the use
> of GNU Global. semantic-symref now happily uses my GNU Global database.
> At this point, what would it take to get the semantic-analyize-
> functions to do completion, jumping, etc.? I suspect simply using
> ede-cpp-root-project is too simplistic of an approach, and that I should
> rather subclass it.
>
> Best,
> David
>
>> -----Original Message-----
>> From: David Ventimiglia
>> Sent: Monday, July 26, 2010 5:52 PM
>> To: 'Eric M. Ludlam'
>> Cc: cedet-devel
>> Subject: RE: [CEDET-devel] EDE Changes
>>
>> Hi Eric,
>>
>> Thanks for the quick reply. Typically (as in, "in my experience"...of
>> course, other readers of this list may have a different experience),
>> only one Ant build file will exist--build.xml--and it will be in the
>> "root" of a project. If that's typical (as I claim), it may in part
> be
>> due to the fact that the tasks in Ant--such as the<javac> compile
>> task--can or can be made to act recursively, chewing through whole
>> source trees compiling every out-of-date .java file found. So if for
>> no other reason than that alone, "recursive Ant" seems not to be the
>> way of things, the way "recursive Make" often is.
>>
>> A more common variation than having lots of build.xml files, however
>> (again, in my experience), is still to have just one build.xml file,
>> but not to put it in the project root, and instead stick it in some
>> off-shoot directory. That seems relevant, because if one were to
>> insist that all "ede-ant" projects have a build.xml file at the
> project
>> root, well then that wouldn't work for projects that like to bury the
>> build.xml file off in some obscure side alley.
>>
>> For Java, or Java-like projects, a suitably "general" solution *might*
>> look like "manually" creating a project by sticking some particular
>> file with some particular properties (maybe a specific name...who
>> knows) at the project root, sorta like the way Emacs JDE seems to like
>> having prj.el files at the root.
>>
>> One further wrinkle (at least) I suppose, is this: many Java
>> "projects" really consist of sub-projects, like this:
>>
>> main-project
>> \project1
>> \src
>> \project2
>> \src
>> \etc.
>>
>> with the package name-cum-include files being rooted off of each \src
>> subdirectory. I think one would like still just to have one project,
>> with one "project-defining file" in, say, \main-project, but still to
>> define source roots relative to that project. The alternative would
> be
>> to put the root files (whatever those turn out to be) in \project1,
>> \project2, etc., but with lots of sub-projects that can get tedious,
>> and I'm not sure how inter-sub-project dependencies would get sorted
>> out (if at all).
>>
>> I'm far from an Ant-expert, however, and I welcome and defer to input
>> from other people who are.
>>
>> Best,
>> David
>>
>>
>>
>>> -----Original Message-----
>>> From: Eric M. Ludlam [mailto:eric@...]
>>> Sent: Monday, July 26, 2010 5:28 PM
>>> To: David Ventimiglia
>>> Cc: cedet-devel
>>> Subject: Re: [CEDET-devel] EDE Changes
>>>
>>> Hi,
>>>
>>> EDE tries to automatically detect a project by the existence of
>> various
>>> project files that might be in those directories. The generic
>> project
>>> type is nice for projects like Make where there is a Makefile in
>> every
>>> directory. It can then walk up the tree, and identify the scope of
>> the
>>> project. If the build.xml files are similar, then you should be in
>>> good shape.
>>>
>>> If there isn't a build.xml in every directory, and perhaps one only
>> in
>>> the root, you may run into a little trouble since if you load in
> some
>>> source file, EDE won't detect it by default since it will think that
>>> directory just belongs to nothing.
>>>
>>> I don't know how ant builds work. If there is only one build.xml to
>>> find, perhaps if you explain how such a project is structured, we
> can
>>> figure out a way to extend ede-generic to make this easier.
>>>
>>> You are correct that the other tools lean on EDE to identify the
> root
>>> of
>>> different projects. It would be great if we can figure out how to
>> make
>>> EDE more universally useful in identifying project types
>> automatically.
>>>
>>> Thanks
>>> Eric
>>>
>>> On 07/26/2010 12:53 PM, David Ventimiglia wrote:
>>>> Hi! I confess, EDE always has been the most mystifying part of
>>> CEDET,
>>>> and I'm afraid I'm still a little nonplussed. I followed the new
>>>> comments in ede-generic.el in order to try to add support for
>> Apache
>>> Ant
>>>> (and Java sources), with the code that's pasted in below. What
>>> happens
>>>> now? Following the pattern of ede-generic-makefile-project, which
>>> says
>>>> that "Makefile" is the buildfile, I've said that "build.xml"
> (usual
>>> name
>>>> of Ant's build files) is my build file. Does that mean I should
>> have
>>>> build.xml in the root of my project? What defines the root of my
>>>> project? I think that defining a project and its root are the
> most
>>>> important parts of EDE for me (more so than project build
> support),
>>>> since evidently it's a prerequisite for using ede-find-file,
>>>> semantic-symref using GNU Global, and the analyzer.
>>>>
>>>> Best,
>>>> David
>>>>
>>>> (require 'ede-generic)
>>>> (defclass ede-generic-ant-project (ede-generic-project)
>>>> ((buildfile :initform "build.xml"))
>>>> "Generic project for Ant projects")
>>>> (defmethod ede-generic-setup-configuration ((proj
>>>> ede-generic-ant-project) config)
>>>> "Set up a configuration for Ant."
>>>> (oset config build-command "ant -f"))
>>>> (ede-generic-new-autoloader "edeproject-ant" "Ant"
>>>> "build.xml" 'ede-generic-ant-project)
>>>> (defclass ede-generic-target-java (ede-generic-target)
>>>> ((shortname :initform "Java")
>>>> (extension :initform "java"))
>>>> "EDE Generic Project target for Java code.
>>>> All directories need at least one target.")
>>>> (setq ede-locate-setup-options
>>>> '(ede-locate-global
>>>> ede-locate-base))
>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>
>>>>> -----Original Message-----
>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>> Sent: Sunday, July 25, 2010 7:26 AM
>>>>> To: cedet-devel
>>>>> Subject: [CEDET-devel] EDE Changes
>>>>>
>>>>> Hi,
>>>>>
>>>>> I had some time to clean up some old projects, so here is a list
>> of
>>>> new
>>>>> features in CEDET from the past week or so.
>>>>>
>>>>> ede-generic.el - Added more commentary to help anyone wanting to
>> add
>>>>> some more project or source types.
>>>>>
>>>>> If you couldn't use ede-generic because it was too aggressive in
>>>>> finding
>>>>> projects, you can now create a file called ".ede-ignore" in any
>>>>> directory you don't want tagged as a project. There is a .ede-
>>> ignore
>>>>> file in the CEDET root. To enable generic project support, use:
>>>>>
>>>>> (ede-enable-generic-projects)
>>>>>
>>>>> ede-simple.el (CVS only) - Consider this obsolete, and try not to
>>> use
>>>>> it.
>>>>>
>>>>> The EDE project that creates Automake files now supports Lex and
>>> Yacc
>>>>> sources. They are not supported in plain Makefile support mode.
>>>>>
>>>>> When EDE creates your configure.ac file, it will do so now with
> an
>>>>> SRecode template, so it is much easier to configure the output.
>>>>>
>>>>> semanticdb-cscope.el - This now works. Use:
>>>>> (semanticdb-enable-cscope-databases)
>>>>> to turn on support.
>>>>>
>>>>> External databases like cscope, global, and idutils now all have
> a
>>>>> common "create" interactive function called
>>>>> `cedet-<tool>-create/update-database'. Thus if you know you have
>>> some
>>>>> tool like global installed, just call
>>>>> `cedet-gnu-global-create/update-database' at the root of your
>>> project
>>>>> to
>>>>> create the databases. These are used in the integration test
>> suite
>>> to
>>>>> test support for these tools is working. I'd like to add support
>> to
>>>>> the
>>>>> EDE Project menu for this too, but haven't gotten that far. EDE
>>> uses
>>>>> these tools for finding files in a project (like includes) so it
>> is
>>>>> quite handy there.
>>>>>
>>>>> Enjoy
>>>>> Eric
>>>>>
>>>>>
>>>>
> -------------------------------------------------------------------
>> --
>>> --
>>>>> -------
>>>>> This SF.net email is sponsored by Sprint
>>>>> What will you do first with EVO, the first 4G phone?
>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>> _______________________________________________
>>>>> Cedet-devel mailing list
>>>>> Cedet-devel@...
>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>>>
>>>>
> -------------------------------------------------------------------
>> --
>>> ---------
>>>> The Palm PDK Hot Apps Program offers developers who use the
>>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a
>> share
>>>> of $1 Million in cash or HP Products. Visit us here for more
>> details:
>>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>>> _______________________________________________
>>>> Cedet-devel mailing list
>>>> Cedet-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>>>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
|