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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
