[CMake] header files with visual studio

[Eric Noulard]

2010/11/10 Oliver kfsone Smith <osmith at playnet.com>:
> Eric Noulard said the following on 11/6/2010 6:20 AM:
>>
>> Initially it may be a pain to list them but after a while its generally
>> better
>> to manually keep track of file (dis)appearing in your source tree.
>> (which is usually what you do when using an IDE without CMake)
>>
>> I.e. if those files are/were added "by hand" into the build system then
>> they
>> must but tracked by explicit list in CMakeLists.txt.
>>
>> The only case (I see) you may faithfully glob for *.h *.whatever is when
>> those are generated files.
>>
>> Not doing that means
>>
>> "I don't care about source file which are added/removed
>>  I just want to compile those"
>>
>> **MY** opinion is that this way of looking to source code is wrong.
>
> You appear to be confusing Revision Control / Asset Management with source
> code editing. And while for smaller projects that may make some sense, it
> breaks very quickly as the project size scales up.

I don't think so, but I'll try to explain myself.

> The solution file for (just) our server systems has 21 top-level projects
> (not counting ALL_BUILD, INSTALL and ZERO_CHECK). Because of the high degree
> of code reuse and overlap, all of the host, client and miscellaneous source
> codes sit side-by-side (although not in any one single directory).
>
> So importing "*/*.{h,hh,hpp}" into the CMakeLists file is nonsensical.

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).

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org