[CMake] Bug? Broken header files in Visual C++ 2008 project

Andreas Pakulat apaku at gmx.de
Thu Sep 4 19:16:16 EDT 2008


On 04.09.08 21:50:03, Alexander Neundorf wrote:
> On Thursday 04 September 2008, Andreas Pakulat wrote:
> > On 03.09.08 23:45:56, Alexander Neundorf wrote:
> > > On Wednesday 03 September 2008, Andreas Pakulat wrote:
> ...
> > > Ah, yes.
> > > What would be cool would be if I could force kdevelop to reread its
> > > project files (... after they have been regenerated by cmake).
> > > Is this possible maybe via DCOP ?
> >
> > Let me check... The openProject() call is in fact available via dcop. Of
> > course this is not a "silent" operation, i.e. the user will get asked if
> > he wants to re-open the current project.
> >
> > I could add the needed functionality, but this won't show up in a stable
> > release for quite some time.
> 
> I think I already thought about this some time ago.
> 
> So:
> how does cmake find the correct kdevelop instance ?
> $ dcopfind kdevelop-*
> DCOPRef(kdevelop-4745,)
> 
> There could be multiple (usually probably not that many).
> It could do for each of them:
> $ dcop kdevelop-4745 KDevProject buildDirectory
> /home/alex/src/CMake/build dir/CMake
> 
> And check whether the build directory is the same as CMAKE_BINARY_DIR. It 
> could also check projectName, but I'm not sure this is necessary.
> So if the build dir matches, which function to call then ?
> 
> $ dcop kdevelop-4745 KDevProject openProject /home/alex/src/CMake/build\ 
> dir/CMake/ CMake.kdevelop
> 
> This pops up a dialog in kdevelop saying "This project doesn't contain any 
> files yet. Populate it ?"
> 
> Why ? The filelist file is not empty.

For some reason kdevelop thinks it is empty. Looking through the source
all it does is reading the entry from the dom, adding
projectname.kdevelop.filelist and checking wether that file exists. It
will also discover an all-lower-case name and rename that to mixed-case.

> Is there another dcop function I could call ?

No, the function is the right one and as I said, if the project is
already open it'll also ask the user wether he wants to re-open it.
There's no "silently re-open this project" function.

> > BTW: This just told me why it is so bad that the cmake generator puts
> > the kdevelop-files into the builddir. The builddir is often enough
> > simply wiped out completely when you want to move it elsewhere or start
> > from scratch - which means losing the project configuration. So at least
> > the .kdevelop file should IMHO be generated in the sourcedir.
> 
> It's not a bug, it's a feature.
> (seriuosly)
> "No files must ever be created in the source dir" (could be read-only, or 
> intended to be packaged as a source package, without any additional files, or 
> different build dirs could use different IDE settings, etc.)

I agree - in the general case. But I hope you can agree that its not
quite good to loose all those customizations one does to the project.
And some of them are completely unrelated to the building process - like
environment variables for execution.

Andreas

-- 
Troubled day for virgins over 16 who are beautiful and wealthy and live
in eucalyptus trees.


More information about the CMake mailing list