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

[BRM]

Sorry for not posting in-line, but the Yahoo! e-mail editor makes it quite hard...

CMake does a wonderful job at _managing_ build systems and helping with projects move between environments, and yes even IDEs, etc. It's one of the big reasons I like it - the fact that I can run CMake and get Makefiles, and run it again - generate the build system for another tool that works via an IDE. I do it frequently with the projects I use it for.

Furthermore, the 'build environment' (e.g. KDevelop3, Visual Studios) should not need to have any concept of what CMake does. It ought to ignore it. CMake, like GNU Autotools, abstracts the source from the build tools themselves. _However_, it should generate projects that work consistently with the expected process flow of the build environments it supports via its generators. And (IMHO) I would argue that _not_ having functionality such as the proposed ADD_HEADER() violates that concept.

In essence - yes, CMake is not a project management tool. BUT it is a build system management tool, and like it or not, that means it is also part of the build workflow process management chain, which carries with it expectations on how it interfaces with certain generators such as IDEs, and the generally accepted (by _its users_) workflow for those IDEs.

BTW, this is not a big thing to be asking for. I wouldn't also define an ADD_HEADERS() as being "project management".  We're still talking about build tools and build systems. Some (e.g. IDEs) carry additional expectations that others don't. So for those that do have those expections, and ADD_HEADERS() would be great to have and the generators can make use of; for those that don't, the generators can simply ignore it.

Ben



----- Original Message ----
From: Andreas Pakulat <apaku at gmx.de>
To: cmake at cmake.org
Sent: Thursday, August 28, 2008 3:26:36 PM
Subject: Re: [CMake] Bug? Broken header files in Visual C++ 2008 project

On 28.08.08 10:16:48, BRM wrote:
> My objection is to do thing following (taken from John's example):
> 
> ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
> ${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_HDRS}
> ${UPMC_CROP_MOC_HDR} ${UPMC_CROP_RC_SRCS} ${UPMC_CROP_UI_HDRS}
> )
> 
> I would rather having something like this instead:
> 
> ADD_HEADER( CropDICOMImages  ${UPMC_CROP_HDRS}
> ${UPMC_CROP_MOC_HDR} ${UPMC_CROP_UI_HDRS}
> )
> ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
> ${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_RC_SRCS}
> )
> 
> 
> 
> The
> first tells me all that stuff goes into compiling the project; but it
> ends up making things confusing as it ends up calling the headers
> "source".
> 
> The second tells me that the *_SRCS actually make up
> the executable, and the *_HDRS are just headers and NOT part of the
> source but something else.

But why should the _buildsystem_ have to declare any of this? There's no
point in doing that, just because some of the generators can't cope with
the header files not being listed somewhere. IMHO the generators should
instead be changed to include those headers into the projects for the
IDE they generate project files for.

> When working with projects I tend to
> put headers into different areas based on their use - are they solely
> for that project (okay, #include "<header>" and its in the same
> directory), or are they shared (okay, #include <header>, and its
> in a common include directory).  In some respects, it would be nice to
> be able to even differentiate them in the IDE - common headers vs.
> project headers - but that could probably be done using the filters,
> etc. (no biggie); _BUT_ I can't get them to even come up unless I treat
> them as SOURCE, which they are not - they're just definitions of what
> is in the source for shared usage.

IMHO the approach to regenerate project description files for an IDE
from a buildsystem tool is simply broken. A buildsystem will never
support all the things in a more complex IDE, so you either stick to
what it generates and never change the result or you change the settings
here and there but then you can't have CMake re-generate the project
files.

> This is probably what has kept me from using KDevelop3 as much too - I tend towards using CMake to generate Makefiles under Linux b/c it's easier to get to things than trying to find a source file with
> the header in KDevelop3 since I can't (by CMake's functionality) add
> headers to the project.

KDevelop3 doesn't need that information at all, or rather it completely
ignores the CMake files anyway. 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. Instead just use the FileTree to update
the list of sourcefiles every once in a while (see the context menu for
"Add files to project"). If you don't like your .kdevelop file in the
builddir you can just use KDevelop's "Import existing project" feature
to import any CMake source dir, setup the builddir for it and be done
with it.

>  It's the same with Visual Studios,
> though I have tended to use VS more for other reasons. (I haven't
> decided on an IDE under Linux, and have historically just used
> Vi+virtual consoles/konsole to do development; where as all my Windows
> development has typically been under Visual Studios.)
> 
> Any
> how...I think the differentiation (clarity) provided by the
> ADD_HEADER() proposed above would be good and helpful to a lot of
> others than just myself.

But it adds nothing to the buildsystem. The CMakeLists.txt files are
purely for building your project, not for managing it. CMake is not a
project management software, its a buildsystem.

Andreas

-- 
Think twice before speaking, but don't say "think think click click".
_______________________________________________
CMake mailing list
CMake at cmake.org
http://www.cmake.org/mailman/listinfo/cmake