[RFC] Buildtools and Language Support

[Andreas Pakulat]

On 13.07.07 08:38:42, Kris Wong wrote:
> > Roberto already mentioned this somewhere in the "qmake third 
> > iteration"
> > thread.
> > 
> > Buildsystems such as qmake, cmake and even automake (especially the
> > autoconf part) have a simple programming language to do "advanced"
> > things (like creating dependecies between different subprojects,
> > executing commands to generate source....). So I (and obviously also
> > Roberto) am thinking: Why don't we create language plugins for such
> > advanced buildsystems?
> > 
> > Reasoning: We already create parsers for each language and AST's, we
> > also build structures on top of that to resolve variable values,
> > evaluate certain functions (cmake macro's, qmake functions). So IMHO
> > we're already doing pretty much everything a language plugin for the
> > qmake or cmake language would do. A DUChain for QMake or 
> > CMake files may
> > help to ease the implementation of these things, I think and 
> > maybe even
> > implementing the "typing-help" that seemingly both CMake and QMake
> > support are aiming at for advanced project buildsystems.
> > 
> > I'm not sure wether this would be 2 separate plugins or 
> > wether its just
> > one plugin implementing both buildsystem and language API. 
> 
> The only reason I can see that you may want to separate the two is if we
> want the user to have code completion when editing a project file (i.e.,
> CMakeLists.txt) when a project of this type is not loaded, and you don't
> want the overhead of loading the build-system stuff at that point.
> Personally I would recommend keeping it all together in one plugin.

Oops, I didn't even think about that possibility :) However I don't
think there's that much overhead from the build-system-part. Mainly that
part is just some gui stuff for adding/removing files and do things like
add include dirs and libs (I don't plan to do anything more in a gui)
and some code to inject such things into the original files. So I'm with
you in that it should be fine to have just 1 plugin for both parts.

> > So what do those that already worked on language plugins in KDevelop4
> > think about it? Does it make sense? Am I overlooking thins in both
> > language and buildsystem support that make this unpleasant or
> > impossible?
> 
> My main concern would be whether the language constructs for each of
> these build systems could easily represented by the duchain, or whether
> there would have to be a lot of work done for this to function properly.

I have to admit that I don't have enough knowledge about duchain to
comment on that. So lets see what constructs qmake haa:
qmake has variable-assignment, function calls which create a new context
(duchain-context) and named contexts. there are some built-in functions
for which there's no declaration, but any user-supplied function has a
proper declaration (via a function-call+context with the
implementation).

So except the named-scope I think those things can be represented by
classes from the duchain. Am I wrong?

For cmake I think its even easier, because it doesn't have named
scope's, its really much closer to a scripting language than qmake.

> To get code completion for a build system file (assuming it was
> implemented in the plugin), it would be simpley a matter of letting
> the language controller know that the langauge support is loaded and
> having a proper MIME type.

Oh, thats cool. By the current development in the C++ support I thought
that each language part would have to do implement quite some extra
classes to get code-completion working. OTOH I didn't look into that too
much :)

Andreas

-- 
Accent on helpful side of your nature.  Drain the moat.