Buildtools and Language Support

Hi,

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. 

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?

Andreas

-- 
Abandon the search for Truth; settle for a good fantasy.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> -----Original Message-----
> From: Andreas Pakulat
> 
> Hi,
> 
> 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.

> 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.
Other than that it seems like a good idea.  If there are
enough
similarities that we don't end up making complete
specializations of the
duchain for each build system (in which case we are not
really gaining
anything), then I'd say it at least worth looking into.  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.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> -----Original Message-----
> From: Andreas Pakulat
> 
> > 
> > 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).
> 

That's one large issue with build systems (especially
qmake).  There is
a tone of built-in functions and variables for which there
are no
delcaration.  For proper language support these things would
have to be
represented in the duchain.  Which likely means having to
insert them
all manually.  Which then means keeping all this information
up to date
as the build system changes.

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

One issue that comes to mind is the whole idea of
sub-directories for
build systems.  i.e., One directory simply has a project
file that
informs the build system to look into these other
directories.  DUChain
is currently setup for handling c++ source files, which are
all
independet translation units.  There is no relationship
between them,
persay, so this type of thing cannot be represented by the
current
DUChain (unless sub-directories could be thought of as child
contexts of
the build system file that "included" them...
maybe/maybe not?).
Something to think about.

> 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 

Allow me to clarify.  By my comment "assuming it was
implemented in the
plugin", I was referring to the extra classes required
to get code
completion working. =]

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel