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

[BRM]

> ----- Original Message ----

> From: Andreas Pakulat <apaku at gmx.de>
> To: cmake at cmake.org
> Sent: Wednesday, September 3, 2008 3:59:08 PM
> Subject: Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
> On 03.09.08 17:52:02, Alexander Neundorf wrote:
> > On Thursday 28 August 2008, Andreas Pakulat wrote:
> > > On 28.08.08 10:16:48, BRM wrote:
> > ...
> > > IMHO the approach to regenerate project description files for an IDE
> > > from a buildsystem tool is simply broken. 
> > Well, it has to. Otherwise the project file become wrong. That's not a big 
> > problem for the makefile-based project generators (KDevelop, Eclipse, 
> > CodeBlocks), but a real one for XCode and MSVC.
> Yeah, I guess I'm really just too used to proper IDE's that don't
> re-invent the wheel and separate buildsystem from project config
> properly. 

Unfortunately as others have already pointed out - "proper" something that IDE developers have yet to agree on.
And unfortunately MSVC and XCode are probably the heavy weights for C/C++ development at this time too.

> > > > since I can't (by CMake's functionality) add headers to the
> > > > project.
> > So if you do 
> > add_executable(foo foo.c foo.h)
> > foo.h is ignored and doesn't appear in the list of project files ?
> As far as I understand that does work, but its not what BRM wants,
> because the header files are not compiled at all.

I'm sure it does work as you say, and that is correct - it's not what I want.
Consider the following structure:

projectdir/
projectdir/include
projectdir/source

Now, there is a CMakeLists.txt file in projectdir/ and on in projectdir/source (perhaps one in every sub-directory of it too).
The header files are all stored in projectdir/include; the source files are all in projectdir/source. In other words, there is a clear delineation of what is compiled and what is not.

Now consider that there may be common files used by several projects, and a directory structure similar to the following:

dir/include/
dir/project1dir/
dir/project2dir/
...

Now using the same structure in MSVC, I can tell the project itself about its header files - whether they are internal to it (e.g. dir/project1dir/include) or shared (e.g. dir/include); but as CMake presently works (without the ADD_HEADER()) I cannot get CMake to do the same for all IDEs that support such a feature through a simple means. The only choice I am presented with is to make precompiled headers and add them as source, but I am not working with (nor do I desire to work with) precompiled headers or call my headers source - they are explicitly not source, just _definitions_ of functions, structures, types, and objects.

Is this not a simple concept?

Since I can't do the above, I currently have to search around the source files that are part of the project to find one that includes the header file I want to look at, and then use the IDE's functionality to oen it through the #include statement. Where as before, I could have just opened it from the file list in the IDE. Quite annoying I must say, but the only way to work with projects generated by CMake at the moment.

> > > KDevelop3 doesn't need that information at all, or rather it completely
> > > ignores the CMake files anyway. 
> > 
> > Which files do you mean with "the CMake files" ?
> Everything related to CMake, i.e. CMakeLists.txt, the stuff in the builddir and so on.

Yes, everything in the CMakeLists.txt file - the directories being recursively processed, the source, the headers, the preprocessor defintitions, etc. (Note: I may include one set of headers for one platform and a different set for a different platform. Platform = OS+Processor.)

> > The generator for KDevelop3 projects in CMake is ok if you want to get an
> > initial project status, but after that you shouldn't use it anymore. 
> > Why ?
> Because it overwrites project settings that you have in the .kdevelop
> file. Thinking about it, the KDevelop3 generator should probably only
> touch the .filelist and only create the .kdevelop file if its not there
> yet. Or has that improved since I last tried it out? (which is quite
> some time ago to be honest).

FYI - as stated earlier, I will switch being build types - clear out all the generated project data and switch to a different build system; or re-run CMake to update the build system when a new file(s) has been added to the project. Eventually, I will be even adding dependency information (to perform SVN exports of _released_ modules - not head, but specific releases) to ensure all dependencies that are within my repository are satisfied in a consistent manner and programs don't get borked b/c of a change one module made.

Like it or not, CMake does do project management _when_ you define project management as managing the source and dependencies that builds the project. CMake already does a lot of that by auto-detecting dependencies (e.g Qt, KDE, etc.); and adding custom commands to checkout specific releases of internal code is fine - they're custom to the project. (Though a generic command would be nice; I don't recall it being there already....however, I won't complain/ask for that; integration to the revisioning system is not something CMake should necessarily do.) However, it does do an excellent job of managing build environments and ensuring that people using different build environments can easily work with each other on the same source. For that, what I have said about Cmake is necessary; and CMake is perhaps the only current tool that does it well. (Autotools doesn't compare as they only support the the Unix-centric Auto-tool chain and specifically Makefiles.)
Generators for build systems that support the concept (e.g. MSVS/MSVC/MS Build) should implement it; those that don't (e.g. Makefiles) simply ignore it and continue on - it's an aid for the heavy lifting tools (e.g. IDE's), nothing more.

Any how...unless I see it come up here, then I guess I'll have to eventually develop my own patch to fix it properly.

Ben