[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