Issue with parsing of conditionally compiled code or how to force parser to process the code under conditional compilation
e.a.agafonov at gmail.com
Tue Jun 26 12:40:30 BST 2012
Right, removing ~/.kdevduchain forces project re-parsing and defines are
I'll try to find out suitable scenario and fill a bug.
Thanks a lot, Eugene Agafonov.
On 06/26/2012 01:56 PM, Andreas Pakulat wrote:
> I guess its re-using the duchain cache instead of parsing from the
> beginning. I don't know the intended or actual semantics of the
> corresponding code, but the parsing-trigger you see for the apply/ok
> button is the only public API that exists. If you can find a small
> reproduction case with a simple project, I'd suggest to file a
> bugreport against the C++ language support.
> On Tue, Jun 26, 2012 at 10:36 AM, Eugene Agafonov
> <e.a.agafonov at gmail.com <mailto:e.a.agafonov at gmail.com>> wrote:
> It seems to me the original problem I've faced is solved with
> Custom Build plugin
> I've finally get the plugin working. Thanks for a great job!
> I've faced another issue: new defines are not applied immediately.
> I've restarted kdevelop
> several times before defines are applied. No exact scenario yet :-(
> I've added some logging into CustomBuildSystem::defines and
> CustomBuildSystem::includeDirectories to make sure they return
> data I've entered. They do actually but it looks like defies are
> not applied immediately as soon as added. It seems to me the
> parser need to be kicked somehow.
> As I can see the background parser job is started as soon as
> Apply/OK button is applied on Custom Build build settings dialog
> but it is not enough to apply newly defined macro.
> Any ideas?
> Thanks a lot, Eugene Agafonov.
>> On Mon, Jun 25, 2012 at 10:44 PM, Eugene Agafonov
>> <e.a.agafonov at gmail.com <mailto:e.a.agafonov at gmail.com>> wrote:
>> I've faced an annoying issue with C++ parser. It does not
>> enable declaration-definition navigation if it decides the
>> code is not compiled due to conditional compilation.
>> It is really predictable behavior but it is an issue if macro
>> is not defined in any header file but defined as compiler
>> command line option.
>> The main question is: Is it possible to tell the parser that
>> some macro is actually defined somewhere in universe and it
>> shall threat it as defined while parsing the source code.
>> Yes, this is typically the job of the buildsystem manager, the
>> parser asks it about the defines for a given file/folder or
>> target and the buildsystem manager should provide them based on
>> the selected build directory
>> Any way, it would be useful to set macro value for parsing
>> as it is done for custom include paths.
>> If you have cmake, then the parser not getting all the defines is
>> to be considered a bug, though there are ways of using cmake
>> which kdevelop cannot support.
>> If you use some other buildsystem, I'd suggest using the Custom
>> Buildsystem Plugin:
>> It allows to configure which defines should be set for which
>> source folder of the project and the parser will be able to fetch
>> this information.
>> kdevelop mailing list
>> kdevelop at kdevelop.org <mailto:kdevelop at kdevelop.org>
> kdevelop mailing list
> kdevelop at kdevelop.org <mailto:kdevelop at kdevelop.org>
> kdevelop mailing list
> kdevelop at kdevelop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop