CEDET

Hi,

I ran a full build locally, but ran into no problems.  There is also a 
build-server that David E runs that does a build and runs the tests, but 
it reported no errors lately either.

You may need a fresh checkout.  I've seen CVS produce incomplete files 
perhaps 2 or 3 times a year on this mailing list.

Eric

On 07/27/2010 06:31 PM, Stephen Johns wrote:
> I've build CEDET on various systems in the past, this is the first time
> I've had a problem. :(
>
> Per the trouble shooting in the INSTALL file:
> I tried the make clean calls: no change
> I tried checking out from the CVS, but got different errors, so went
> back to pre7.
>
>
> Build info below:
>
> OS: CentOS release 5.5 (Final)
> EMACS: GNU Emacs 21.4.1
>
> Error is:
>
> While compiling semantic-gcc-setup in file
> /xxx/emacsLisp/cedet-1.0pre7/semantic/bovine/semantic-gcc.el:
> ** reference to free variable exec-suffixes
> While compiling the end of the data in file
> /xxx/emacsLisp/cedet-1.0pre7/semantic/bovine/semantic-gcc.el:
> ** The following functions are not known to be defined: locate-file,
> semantic-c-reset-preprocessor-symbol-map
> Wrote /xxx/emacsLisp/cedet-1.0pre7/semantic/bovine/semantic-gcc.elc
> Done
> make[2]: *** [languages] Error 1
> make[2]: Leaving directory `/xxx/emacsLisp/cedet-1.0pre7/semantic/bovine'
> make[1]: *** [bovinator] Error 2
> make[1]: Leaving directory `/xxx/emacsLisp/cedet-1.0pre7/semantic'
>
>
>
> ------------------------------------------------------------------------------
> 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

Hi,

On 07/28/2010 08:38 AM, Christoph wrote:
> On 7/28/2010 5:30 AM, Eric M. Ludlam wrote:

>>> Other notes, questions etc.:
>>>
>>> - Can highlighting on semantic-ia-fast-jump be disabled entirely?
>>
>> It cannot. It could certainly be made into an option though. Are you
>> looking for this on a global scope, or for individual commands?
>
> Ok, an option is kind of what I was looking for.

I checked in a change to pulse.el (in CEDET/CVS) that lets you set 
pulse-flag to 'never to disable pulsing completely.

>>> - No indication that Semantic mode or any of its minor modes is active
>>> in mode line.
>>
>> Correct. It used to, and the mode line got over full of bits that were
>> effectively useless. A global 'semantic mode' may be useful though. The
>> version of CEDET I've been working on doesn't have a semantic mode.
>>
>> I can usually tell because the decoration mode turns on and it becomes
>> obvious.
>
> What does "It doesn't have semantic-mode" mean?

When CEDET from CVS is used, the recommended initialization routine 
turns everything on.  In Emacs, CEDET is a part of Emacs, so Chong wrote 
a `semantic-mode' function that will turn things on, and also turn 
things off.

Thus, there is no semantic-mode in CEDET/CVS.

Eric

Hi,

I don't have a good quick answer on this one.  It is probably possible 
to use ede-cpp-root to just mark the root of your project, but it won't 
have many useful features.  It will just mark the root of your project.

I've wanted to put an EDE wrapper on top of JDE, but this is not my 
domain.  EDE would basically let JDE do the work, and then propagate the 
root of the project to those tools that need to ask that question of EDE.

I think there are a lot of build environments that don't have project or 
build files in every directory, so it will be useful to come up with a 
general scheme for identifying them.  I've always been cautious of 
walking up directories if I don't know for sure I'm in a project, 
because there can be big performance issues walking across / or through 
automounters before stopping.

If anyone has some clever ideas for protecting against too much file 
system scanning in this type of environment, let me know.

Thanks
Eric

On 07/26/2010 08:51 PM, David Ventimiglia wrote:
> 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
>>>
>