[Insight-developers] Making metaio a configurable namespace

Karthik Krishnan Karthik.Krishnan at kitware.com
Mon Mar 20 15:42:20 EST 2006


Stephen R. Aylward wrote:

> Looking closer - why did you make it a configurable namespace?
>
Sorry for complicating things, but the point was to have the same code 
base, MetaIO shared between ITK and VTK, so its CVS repository would 
just be a symlink on the CVS server, as it is for KWsys, to be 
consistent and to reduce maintainence.

> The seems quite complicated to me - I completely understand what 
> you've done, and what you've done is a very cool use of CMake, but 
> these changes introduce non-standard commands (#include 
> METAIO_HEADER(headerfile.h)) and config options that will scare away 
> other casual users and developers.   We need to remember to program 
> for casual users, not just experts.

Yes, I agree it makes the code harder to follow with non-standard syntax 
for the includes etc..

>
> Also, your modifications move the location of the .h files - as a 
> result every project that uses MetaIO directly will need to modify 
> their CMakeLists.txt file to include a new include directory path. 

Yes. I think this is necessary. The configuration is necessary to do a 
regex match and substitute for @META_NAMESPACE@ directives that #define 
I think cannot do.

For instance a header metaImage.h might look like
#ifndef __ at META_NAMESPACE@_METAIMAGE_H
#define __ at META_NAMESPACE@_METAIMAGE_H
...
#endif

Even if the META_NAMESPACE preprocessor macro was available at compile 
time, it wouldn't substitute this:

#ifndef __META_NAMESPACE_METAIMAGE_H
#define __META_NAMESPACE_METAIMAGE_H
...
#endif

It needs to be a seperate word.

The result is that if you have code that reads:

#include "itkmetaio/metaimage.h"
#include "vtkmetaio/metaimage.h"

the latter will never included included.

Or am I wrong here ?

The same goes for includes that read:

#include "METAIO_NAMESPACE/foo.h"

It needs to be regex matched.

> This is not backward compatible.   It cannot be accepted into ITK.
>
Unless users go about including directories themselves. I don't think we 
expect anybody to do that. We expect them to include ITKConfig.cmake, 
which contains the right include directories. This would mean we could 
dispute any movement of include files in the ITK tree. For instance 
moving a file from BasicFilters/ to Common/ would not be backward 
compatible ?

> What is the problem that you are trying to fix?
>
> When we had discussed this I envisioned a much simpler solution - a 
> CMake option passed as a compiler var, and in the code a simple 
> bracketing with #ifdefs would enable/hide namespace definitions.   The 
> default would be no namespace, so everything would be 100% backward 
> compatible.
>
> Stephen
>
> Karthik Krishnan wrote:
>
>> Hello,
>>
>> Here's the proposal for making MetaIO in ITK a configurable namespace:
>> http://www.itk.org/Wiki/Proposals:Making_MetaIO_a_configurable_namespace
>>
>> The link points you to where you can get the patch, if you need to 
>> try it out.
>> The changes have already been made to a branch in VTK and are awating 
>> a commit in ITK.
>>
>> thanks
>> -karthik
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>


More information about the Insight-developers mailing list