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:
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
I'm far from an Ant-expert, however, and I welcome and defer to input
from other people who are.
> -----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
> EDE tries to automatically detect a project by the existence of
> 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
> 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
> different projects. It would be great if we can figure out how to
> EDE more universally useful in identifying project types
> On 07/26/2010 12:53 PM, David Ventimiglia wrote:
> > Hi! I confess, EDE always has been the most mystifying part of
> > 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
> > (and Java sources), with the code that's pasted in below. What
> > now? Following the pattern of ede-generic-makefile-project, which
> > that "Makefile" is the buildfile, I've said that "build.xml" (usual
> > of Ant's build files) is my build file. Does that mean I should
> > 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
> >> 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-
> >> 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
> >> it.
> >> The EDE project that creates Automake files now supports Lex and
> >> 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
> >> tool like global installed, just call
> >> `cedet-gnu-global-create/update-database' at the root of your
> >> to
> >> create the databases. These are used in the integration test suite
> >> test support for these tools is working. I'd like to add support
> >> the
> >> EDE Project menu for this too, but haven't gotten that far. EDE
> >> 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
> > of $1 Million in cash or HP Products. Visit us here for more
> > 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