[CMake] header files with visual studio

[Eric Noulard]

2010/11/13 Oliver kfsone Smith <osmith at playnet.com>:
> I mostly work with emacs/vi and - prior to CMake - Makefiles. I'm still
> mostly working with emacs/vi, but I also do a fair amount of work with
> Visual Studio and CodeBlocks, primarily when I need to test client
> interactions with server processes.
>
> Manually maintaining duplicated lists of #includes is data duplication: Like
> manually maintaining dependency lists. If we had to do that with CMake, well
> I doubt we'd be having this conversation in the first place because we
> probably wouldn't be /using/ CMake.

OK and off course you are right.

> So I don't understand why you would feel differently about having those
> lists automatically transcribed to the resultant IDE solution/project files.

You are right again and I was not looking at that this way.
I do (may be did?) have mental dichotomy between the "build process"
(for which I expect just like you an automatic dependency handling from CMake)
and "source management process" for which *.h
(or any #included file) and/or *.c (or any "compiled" file) are just source
like others which I have to manage explicitely,
either with SCM tool or inside CMakeLists.txt.

But may be I shall step back and just think differently about it and even if
I need to explicitly use SCM for headers may be they shall just "disappear"
from CMakeLists.txt?
May be the public "exported" headers would still appear in the CMakeLists.txt
but most of them can just go away.

I think Michael did get your point and I didn't, sorry about that.

Now re-reading the Michael post it seems that having some hook
(or property)
to get dependency list from a particular file (or target) should be
the way to go.

There has been some discussion on the list about improvement
of the dependency scanner, this kind of idea may be examined there.
May be it's worth filing a feature request on this subject.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org