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@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
