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