[Insight-developers] Making metaio a configurable namespace

[Karthik Krishnan]

What if you write have an application that has:

How do you define the initial
#ifndef..
#define ..

tags in the header file of say metaImage.h ? It needs to be different 
for the header files in each toolkit because the header files are 
different .

What if an application has something that reads

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


Julien Jomier wrote:

> Karthik,
>
> I don't see why the following would not work:
>
> ----
> #define META_NAMESPACE metaITK // to be defined in a config file
>
> #ifdef META_NAMESPACE
> namespace META_NAMESPACE {
> #endif
>
> class Meta...
> {
> ///
> };
>
> #ifdef META_NAMESPACE
> } // end namespace
> #endif
> ----
>
> It's unlikely that one application calls the same header file from 
> meta twice.
> Also why do we need #include "METAIO_NAMESPACE/foo.h"?
>
> Maybe I'm missing something,
>
> Julien
>
> Karthik Krishnan wrote:
>
>> 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
>>>>
>>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>