Yes, I think I misinterpreted your question.
It is true that if the header C.h changes on disk, and CEDET needs to
reference it, it will notice based on time stamps and reparse that file
as needed. It also keeps track of all the macros created by the header
If you know that some header like C.h owns a set of macros that are
important, you can specify that in your project or with
semantic-lex-c-preprocessor-symbol-file at a global level. If you do
that, all files will obey those macros.
What is missing is when the general context of active macros changes,
and forcing files to be reparsed. In such a case, if the user changes
that state, you really need to just delete the cache and start over. It
could probably be automated in some way, but the case where A.c and B.c
(old example) are in two different projects with different macro states,
and C.h is in /usr/include, things get a little weird since that state
changes and you just switch your current buffer.
For that to work, we'd need a database on a per-project, with new
variants of /usr/include parsed on a per-project basis. A faster parser
would be good then too. ;)
On 06/12/2010 07:56 PM, John Yates wrote:
> Obviously I was not clear enough. I intended "source dependencies" to mean a header. That said I made my assertion based only on a expectation of how CEDET behaves, not based on actual knowledge. Eric, do correct me if my expectations are misplaced.
> WRT your example. Your explanation to Bogdan made it clear that CEDET does not expect the significance of C.h to be influenced by the contexts into which it gets included. Thus I completely accept that neither changing A.c nor B.c triggers a reparse. But I would expect editing C.h at some point to induce an update of the database. Similarly, CEDET already expects the set of predefined symbols supplied by one's .emacs to influence the parsing / interpretation of headers. I think that we all expect such definitions to be quite stable. But when they do get changed expecting the user to know what databases need to be invalidated and further expecting the user to remember to do so is simply begging for a poor experience.
> The simplest solution would be to tag each database with the complete set of defines in effect at the time that it was populated. Then so long as the set of defines attached to the database matches the current set of defines the database remains valid. Once a mismatch occurs the conservative solution is to drop that database and to start afresh.
> A less drastic solution would be to tag each database with the set of defines referenced during its construction. Then so long as those defines remain in the current set the database remains valid.
> From: Eric M. Ludlam [eric@...]
> Sent: Saturday, June 12, 2010 1:57 PM
> To: John Yates
> Cc: Bogdan Graur; cedet-semantic@...
> Subject: Re: [cedet-semantic] symbol parsing problem [fixed]
> Hi John,
> If you had two files open, A.c and B.c and both #include C.h, and if
> CEDET then reparsed C.h every time you edited either A.c or B.c, then
> that is a lot of parsing time spent on what is most likely a not useful
> activity. If you start a fresh emacs with an empty tag cache, and then
> ask CEDET to reparse all dependent files on some miscellaneous file you
> have, then that is what you would get on every edit if CEDET worked that
> Dependencies like this are pretty rare, and easy to overcome, though it
> adds to the learning curve. Pulling a dependency set together that
> actually knows about which #defines are needed to make which .h files
> accurate would be quite the challenge to assemble.
> On 06/12/2010 10:33 AM, John Yates wrote:
>> CEDET understands to reparse when source dependencies change. Should it not also validate its database(s) against the changes in search path and predefined symbols?
>> From: Eric M. Ludlam [eric@...]
>> Sent: Friday, June 11, 2010 9:06 PM
>> To: Bogdan Graur
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] symbol parsing problem [fixed]
>> On 06/11/2010 06:24 PM, Bogdan Graur wrote:
>>> Thank you Eric for your help!
>>> adding the marked line in the project definition (in ~/.emacs file) did
>>> the trick:
>>> (setq test-project
>>> (ede-cpp-root-project "test"
>>> :file "/projects/test/test.cpp"
>>> :include-path '("/")
>>> * :spp-table '( ("PROTO" . "1") )
>>> * ))
>>> I am sure I have tried this before posting here but it only worked after
>>> deleting the ~/.semanticdb directory.
>> I'm glad you found the solution.
>>> Maybe it was created before adding the :spp-table customization and no
>>> longer took into consideration my modified project?
>> Yes, to minimize time spent parsing files, CEDET will keep pre-parsed
>> file data around. A side effect is that when you change parsing data
>> (like the preprocessor table) you need to manually flush your cache.
>>> Having a global ".semanticdb" directory (shared probably for multiple
>>> projects) can cause any problems like the one I described earlier?
>> It is more about the aggressive data caching that causes the issue. I
>> don't think it matters where the data is stored.
>>> Is it possible to have separate ".semanticdb" directories for each
>>> project defined?
>>> Can one project share many ".semanticdb" dirs?
>> If you set semanticdb-default-save-directory to nil, it will save cache
>> files next to the files that it is caching instead of in .semanticdb.
>>> Where can I find more documentation about how this "database" can be
>> There isn't much you can do as far as configuring where the databases
>> are stored other than the above, nor even what they do unless you opt to
>> start coding up new ones, in which case there isn't much doc for that
>> either, just examples.
>> The file backed semantic databases are just one variant of a tag
>> database. There are also databases backed up by GNU Global cache files,
>> EBrowse cache files, CScope cache files (Not finished yet) or even one
>> that is custom to the Emacs environment. Creating new specialized
>> databases is a good way to improve performance.
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> cedet-semantic mailing list