[CMake] header files with visual studio

Oliver kfsone Smith osmith at playnet.com
Sat Nov 13 16:45:57 EST 2010


Eric Noulard said the following on 11/11/2010 5:53 AM:
> Having a lot of source code re-use from "source modules" that can be shared
> between several projects is off course a necessary goal when your source
> code base grows and the set of projects using those goes along the same curve.
>
> My experience is in this case you may have mainly two kinds of re-use:
>
> A) "external-like" re-use were the reused module is an autonomous
>        [set of] library and executable.
>       CMake may handle this using "ExternalProject_Add" module
>       and the module may have his own CMakeLists.txt containing the toplevel
>       PROJECT(...)
>
> B) "internal-like" re-use. You may import the source but the imported
>       source may not be compiled autonomously and should be plugged
>       somewhere in the project source tree using the module.
>
>       In this case ecah "internal-like" module may be shipped with
>       a SourceDescription.cmake file which (manually) define appropriate
>       set of CMake VAR (<MODULE>_SRC_FILES,<MODULE>_HEADER_FILES, ...)
>       which can be included by the upper-level using project.
>
> A-type project are edited (and source-controlled) on their own.
> B-type project may be edited in any user project,
>    how you handle source control in this case depends on your organisation
>    and project inter-dependency management.
>
>> What I was hoping to achieve was a "Header Files" folder along side each
>> "Source Files" folder so that the headers were pertinent to any given
>> project within a solution.
> Does CMake "source_group"  will do the jobs if each sub-project
> is defining its list of<MODULE>_<KIND>_FILES?
>
> Now, I admit I'm not a usual Visual Studio user so you are pretty right with
> the fact I didn't face any performance issue on big project with VS.
>
> I did work on relatively big source project with many imported modules
> (external-like or internal-like) but we were not using any IDE  just
> emacs/vi etc and a big set of Makefiles (no CMake usage at that time).
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.

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

- Oliver



More information about the CMake mailing list