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.
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.
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.
http://www.kfs.org/~oliver/solution.jpg
_______________________________________________
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
