Review Request: Add support for "language features"

[Alexandre Courbot]

> On July 4, 2012, 7:28 a.m., Aleix Pol Gonzalez wrote:
> > Do we really need to add a dependency between ILanguage and the Project system?
> > 
> > Isn't too abstract to pass a string list only? How is the buildsystem supposed to know what to return?

The ILanguage introduction in IBuildSystemManager is necessary because the same file could contain several languages, therefore we need to discriminate between them. Instead of a reference to ILanguage we could use a string with the name of the language - because basically I don't think there is use for more than the name() method in there.

About using a string list, this is exactly the place where you want to be abtract. Language features are a contract between language support and the build manager. The returned values only make sense to the targeted language support. For instance, CppLanguageSupport would recognize strings such as "C99" or "C++11" and tune the parser accordingly. But you can also imagine that this could be extended to contain other information like additional defines or include paths, although we have other functions (defines, includeDirectories) in IBuildSystemManager that serve these specific purposes. Btw, these are *not* abstract enough IMHO, since they bring very C-like concepts (defines, includes) down into the IBuildProjectManager interface, which should be generic. They would be better-fitted as the second or third members of the QStringList, for instance. Of course every language would need to have its own convention as to what is returned and where that both build managers and language supports should follow.

What do you think should be returned instead of a QStringList here?


- Alexandre


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105299/#review15358
-----------------------------------------------------------


On June 20, 2012, 1:43 a.m., Alexandre Courbot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105299/
> -----------------------------------------------------------
> 
> (Updated June 20, 2012, 1:43 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> Add support for "language features"
> 
> Sometimes the same language can run using different variants - the most
> obvious example is the C++ language support, which may also support C
> and other variants and behave differently according to the type of file.
> 
> This patch adds a new method to IBuildSystemManager allowing it to get a
> list of features to pass to ILanguageSupport::createParseJob as an
> additional argument. ILanguageSupport can then adapt the behavior of its
> parser according to the features the build manager says the parsed file
> uses.
> 
> Corresponding support for kdevelop (since this patch breaks API compatibility) is there: https://git.reviewboard.kde.org/r/105300/
> 
> 
> Diffs
> -----
> 
>   language/backgroundparser/backgroundparser.cpp 417a8e4b7f38acfa959959895f186c11e3a76f93 
>   language/backgroundparser/tests/testlanguagesupport.h ed3864c9e8da8eed97d3d91500eec6c623fae41e 
>   language/backgroundparser/tests/testlanguagesupport.cpp 3f88894d728610ebd433bff46936f38dcd2138be 
>   language/interfaces/ilanguagesupport.h 22cedf09656aaf80275dd3a14d3752003fe9a912 
>   project/interfaces/ibuildsystemmanager.h c0813d8f781b0be29829b9278f191299af823b68 
>   project/interfaces/ibuildsystemmanager.cpp 74af0e76f8c8bc9276d79ff54be4d3d41927c298 
> 
> Diff: http://git.reviewboard.kde.org/r/105299/diff/
> 
> 
> Testing
> -------
> 
> Compiled kdevplatform & updated kdevelop, checked things were working.
> 
> 
> Thanks,
> 
> Alexandre Courbot
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120705/309388c5/attachment.html>