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

Fri Aug 29 09:50:48 EDT 2008

And yet, we will probably not add ADD_HEADER... (I don't think. Other CMake
devs can chime in here if they think I'm wrong.)
The problem is more than just "sources" and "headers." What about resource
files? Should .bmp and .ico resources show up in the IDE? Yet, they're not
compiled. Are they headers? No, not really. How about inputs to custom
command tools? Are they sources or headers or ... neither? Should we also
have ADD_RESOURCE and ADD_CUSTOM_COMMAND_INPUT and ADD_INFINITUM? If we do
add all these, then why isn't there an ADD_SOURCE?

Everything that is a "source" file of a target should show up as a project
item in the IDEs. If the IDE knows how to edit that type of "source" then,
great everybody's happy. But some "source" files are not compiled. They are
just referenced by things that are compiled.

I understand you don't like thinking of headers as sources, but could your
sources compile without them?

It's up to you to separate things logically in your project according to how
you think of them. From CMake's perspective, to associate an input file with
a CMake target, we think of them as "source" files. Some are compiled, some
are not, some are processed by some other tool that's not even a compiler.

You could always add an "ADD_HEADER" function or macro that tracks headers
for each of your targets in variables and then have your own wrapper around
ADD_LIBRARY and ADD_EXECUTABLE to use them automatically...

HTH,
David

On Thu, Aug 28, 2008 at 8:14 PM, BRM <bm_witness at yahoo.com> wrote:

> 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
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080829/9c998984/attachment-0001.htm>