KDE/kdevelop/languages/cpp

Alexander Dymo dymo at ukrpost.ua
Sun Jul 1 16:30:34 UTC 2007


On 7/1/07, Alexander Neundorf <neundorf at kde.org> wrote:
> Hi Alex,
>
> On Friday 29 June 2007 15:21, Alexander Dymo wrote:
> > > Yes, this is absolutely no problem with the generators. They can export
> > > any information you want, since everything (regarding the build) is known
> > > to them.
> >
> > Yes, export. That's not all we need. We need to "import" our changes
> > back to CMake.
>
> Can you give me an example ?

That's easy. Imagine there's a project with this CMakeLists.txt:

include_directories (${CMAKE_SOURCE_DIR}/lib)
set (foo_SRCS foo.cpp)
kde4_add_plugin(fooplugin ${foo_SRCS})

KDevelop needs to
1) understand what's there and present a project toolview with one
"foo" target inside and allow the user to set include paths in the
target's properties

2a) if the user adds another include dir in the properties (say
${CMAKE_SOURCE_DIR}/lib)
we need to write this change back to the cmake file. To write it back
we need to be able to understand where to write that change and how to
write it (which commands to use, like include_directories for ex.).

2b) if the user adds a target, KDevelop needs to know again where and
how to write the change back to the CMake file

To summarize, we need two-way communication with CMake because users
will want to use GUI not only to read their projects, but also modify
them.




More information about the KDevelop-devel mailing list