Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#3
Here the excerpt from the discussion with Luke (his comments are quoted here) regarding this feature on the "SBIA eLog":https://sbia-infr-vweb.uphs.upenn.edu/elog/Bug+Tracking+and+Feature+Requests+for+Development+Projects/89:
Andreas Schuh replied on Tue Jan 3 11:44:24 2012
- this one is somewhat minor. Over break I did an svn update on my project then tried to build it. gcc gave me
the line number and file of the error, I grabbed the filepath from the error message and fixed the problem
recompiled and everything was fine. The next day i was working on the same project and the error was suddenly
back, because I had been editing the file in the build tree not the src tree. This is somewhat minor as if i had
been really thinking I would have noticed it, however it is somewhat annoying particularly for someone who
doesn't know the project.
I understand this can happen, but this is common for all files in CMake that get configured into the build tree. Of course, when the original file has the
.in suffix and actually changes, it would be more obvious. Still it would not prevent this mistake from happening other than putting a comment at the
top of a .in file stating that this file was generated from a .in file... certainly we don't want to put this comment in a .h file which actually didn't change
and was copied only, though.
- Module dependency: When you turn of a module, that modules header files remain in the build include, meaning
that if you've build a module once in a build tree its files are there. this causes some issue with sorting out
module dependencies. this is also confusing as all the file end up in the final include path
sbia/prjName/header.h etc.
That is on my to-do list already, to remove the deprecated header files from the build tree again.
- code coverage: the coverage reports of cdash are linked to the headerfiles in the build tree. thus the
filenames have no information about what module they are in making finding the file without knowledge of the
project abit more difficult.
Both, 1) and 3) require a clear understanding of what happens to the public header files in the include/ directory. Once more familiar with BASIS and
given that it is documented and these issues are highlighted in the documentation of BASIS, it should be more obvious.
One way to separate the CDash submissions by module could be to use the subproject feature and the LABELS properties as ITK 4 is doing it on their
Modular Dashboard [1]. Not sure if the support for this by CDash is already matured enough.
Another possibility is to use include paths such as include/sbia/// in the build tree. To get this, you would set the CMake variable
BASIS_USE_MODULE_NAMESPACES to TRUE (see config/Settings.cmake file of the HardiTk).
Overall, I am not feeling to happy about "configuring", i.e., copying, all the header files to the build tree just to have the include path set during
configure time of the project, i.e., to turn include/ into include/sbia//, for example. For files which indeed need to be configured as they use
CMake variables in them and thus use the .in suffix, this is fine and part of the contract with BASIS regarding the meaning of the .in suffix. The nice
thing about it is, that in the project source tree, you don't need to have the as well annoying subdirectory structure include/sbia//. As we
talked about it earlier, there is absolutely no better way than having such include path with only the include/ being in the include search path to avoid
a dependency problem regarding the include statements. In case of the modules, it is even better to not have the subdirectory structure as part of the
module's source tree. If you think about the module as a separate project and would indeed build this module separately, the header files end up in
include/sbia// instead, as now the module is the project. On the other side, even though technically possible, the thing about modules is
that they are tightly coupled to the project they belong to. For the rather loose coupling of projects, we will use the super-build concept. So I guess it
is fine to have a path such as modules/HardiCommon/include/harditk/, i.e., one which includes the name of the project the module belongs to.
All that said, what do you think about having a BASIS CMake variable which can be set in you project's config/Settings.cmake file and is used to specify
which of these implementations a project wants to make use of ? Hence, another way to configure BASIS. For example, let the project developer set
BASIS_USE_SOURCE_INCLUDE_DIRS to either TRUE (no copying of header files to the build tree that don't have the .in suffix) or FALSE (the current
behavior). This would also enable a project to define it's own non-standard include path (although this would violate the standard, but could still be
enforced by checking the path of each header file in the source include/ directory and throwing an error if the standard of include/sbia// is
violated).
[1] http://www.vtk.org/Wiki/ITK_Release_4/Modularization/Modular_Dashboard
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-06
Completed: 0