Namespace Issues

On 2003.01.30 16:47 Nicholas Clark wrote:
> On Thu, Jan 30, 2003 at 11:48:05AM -0600, John Lenz wrote:
> 
> > Is there any possibility of NO_EMBED going back in?  It seems to me
> 
> Should we shift the thread to p5p? That's a p5p question. It's not
> clear
> to me why NO_EMBED was removed, but my memory isn't long for embedding
> related stuff.
> 
> Nicholas Clark
> 
The thread in question can be found starting here...
http://archive.develooper.com/perl-xs@perl.org/msg00851.html

Ok to review the thread, a bunch of people using SWIG 
(http://www.swig.org) to create perl modules have been having namespace 
conflict problems. For example, do_open is the name of a private method 
on a class in <iostream> (GNU libstdc++v3) and if the perl headers are 
included before <iostream> then a bunch of compiler errors are 
generated because the perl macro causes the iostream class to produce 
syntax errors.  We have also had some problems with namespace clashes 
in other standard library headers and also code people are trying to 
wrap.

The way we are trying to deal with the problem right now is to undef 
the macro's that cause problems.  Thing is, right now you have to try 
and compile the code, see what macro caused a conflict, add an undef 
back into the input file, and keep going until there are no more 
errors.  But for SWIG we would like to provide a general solution that 
"just works"   So I wrote a perl script that parses embed.h and writes 
a file called noembed.h with an undef for every define, but we are 
hesatent to use it.  Because if we undef do_open for example, will we 
be able to call Perl_do_open(aTHX_...) and have it still work?  Also, 
are those Perl_ function names stable?  That is to say, if we use only 
the Perl_ functions for every call to the perl interpreter (because we 
undef'ed every macro mentioned in embed.h) will that API change between 
perl releases and break the code?  Also, some people use SWIG to 
generate the wrapper file and then compile it on lots of different perl 
versions.

What is the best way to deal with namespace clashes?

John

• Namespace Issues by John Lenz
• Re: Namespace Issues by Gurusamy Sarathy
• Re: Namespace Issues by Jarkko Hietaniemi
• Re: Namespace Issues by Jarkko Hietaniemi