Re: [CEDET-devel] CEDET + JSON compilation database?
Brought to you by:
zappo
From: David E. <de...@ra...> - 2013-12-17 20:34:59
|
Sorry for the delay. Pre-christmas is a busy time, and the Emacs freeze is near, so I had to do some merging. Alastair Rankine writes: >> - Another problem is how you determine the root of the project (meaning >> the :directory slot). In larger builds, source files can come from >> various places in the source tree, and you currently choose the >> directory from the last "file" entry in the json file, but that might >> be somewhere deep down in the source tree. Maybe you could just choose >> the shortest one. Alternatively, I guess you could simply use the >> directory were the compile_commands.json file is located (not sure >> where cmake usually puts it, but at least for 'Bear', that would make >> sense). > > In fact the first option is what it tries to do. See in this code: > > ;; If we haven't set a project dir, or this entry's directory is a prefix of the > ;; current project dir, then update the project dir > (when (or (not newprojdir) (string-prefix-p srcdir newprojdir)) > (setq newprojdir srcdir)) > > Admittedly, the test suite is not sufficient to validate this is working as intended. Ah yes, I see that now. The reason it didn't work for me is that I tried it with a source tree like this: /home/david/project/somelib/src/... /home/david/project/main/src/... The project root is obviously '/home/david/project', but your code above will not detect that, since it does not find the common substring between the different source directories. >> There is a more general problem when dealing with large projects: You >> currently add all include paths, preprocessor symbols, etc., but they >> might be different for each file. In EDE, we currently do not have a >> good solution for this, but your compdb project could do this by >> actually saving those parameters for every file. Maybe it's not worth >> the trouble, though. > > Again, this is exactly what it already does. Yes, sorry. I failed to see that you use a special target for this. > Whether/how this scales to very large projects, I don't know! Me neither. I have to think about that a bit. >> This is a limitation in the preprocessor handling: Semantic does not >> pull in symbols from all includes. That would be way too slow, >> especially with an empty cache and many includes (if you use stuff like >> Boost, you can easily get dependencies on a thousand header >> files). Instead, it only uses those header files which are listed in >> semantic-lex-c-preprocessor-symbol-file, or which you list as an >> implicit include. > > Good to know, thanks. Is there a better way of testing that the macro > definitions are being processed correctly? I guess you want to detect that hello.cpp finds the "world.hpp" include, right? >> Yep, that's a difficult problem. You can use a heuristic like the one >> you describe, and it will probably work 99% of the time. :-) > > My feelings exactly. I think there is already some support for > header/source file matching in CEDET though? I don't intend to blaze > any trails here. There is in Emacs; see `ff-find-other-file'. Cheers, David |