[Insight-developers] PROPOSAL: Flattening headers directory structure at Install time

David Cole david.cole at kitware.com
Thu Apr 17 11:41:53 EDT 2008


Having two ways of organizing your code means you are likely to have to
waste future time dealing with organizational issues. Currently, with one
organization of files/directories, you do not have any of those issues.

If you want to flatten it, why not flatten it by putting all public header
files in one location in the source tree and keep the source tree / build
tree / install tree parallelism that we have now...?

Another benefit of flattening it (and doing it in the source tree itself) is
that it is completely obvious if you are trying to invent a new header file
name that already exists.


(just) 2 cents,
Dave C


On Thu, Apr 17, 2008 at 11:30 AM, Luis Ibanez <luis.ibanez at kitware.com>
wrote:

>
> We have found a couple of issues with the method
> that we currently use for installing the ITK headers.
>
> The current method preserves the tree structure of
> the source three, namely:
>
>
>            Common
>            BasicFilters
>            Algorithms
>            etc....
>
>
> The consequence is that projects that use ITK must
> have all these directories in their include paths.
> This results in something like 10 different directories
> being added to the include paths.
>
> Since there are no name conflicts in the header files,
> we could copy all of them in a single directory.
>
> This will make a lot simpler for users to refer to
> ITK since they will only need to add one include
> directory to their path, and only one directory
> for the libraries.
>
> ITK coding style doesn't use the subdirectories
> explicitly. That is, we never do
>
>   (A)  #include "Common/itkImage.h"
>
> instead we do:
>
>   (B)    #include "itkImage.h"
>
>
> Which means that there shouldn't be any impact
> on ITK code itself.
>
> The potential problem will be for uses who may
> have decided to use the notation (A) instead of
> the recommended notation (B).
>
>
> This is a significant improvement for projects
> that not only used ITK but also link to other
> three or four libraries (e.g. VTK, QT, ...)
> and may reach limits of command line lengths.
>
>
> We could target ITK 3.8 for making this change
> on the installation process.
>
>
>
>  Any thoughts ?
>
>
>   Thanks
>
>
>      Luis
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080417/cf2c5ac8/attachment.htm>


More information about the Insight-developers mailing list