The basic idea behind this approach is that the *compiler* only thinks of
the identifiers by their full (prefixed) names, but the preprocessor knows
how to translate short names into full names. Thus the proj binaries will
only know about the full names.

As long as users leave the name resolution to the linker, and use the
correct header files, it shouldn't matter.

On Mon, May 25, 2015 at 10:26 AM, <sisyph...@optusnet.com.au> wrote:

>   Hi David,
>
> I did suggest something like that, even though I think it’s messy.
>
> Would I need to define PROJ_NO_NAMESPACE_POLUTION when building the proj
> library ? ... or would I need to define it only when building
> PDL::GIS::Proj ?
> (There’s no problem until winreg.h gets included – and that doesn’t happen
> until perl.h gets included during the PDL::GIS::Proj build.)
>
> I’m a bit hazy on what would happen if I built the proj library without
> defining PROJ_NO_NAMESPACE_POLUTION, and then defined the symbol for the
> PDL::GIS::Proj build. (That would not be sufficient, would it.)
>
> Anyway, last communication I received from the proj list was a
> recommendation that they should simply rename PVALUE to something that’s
> not going to clash ... and I’m hoping that’s what they’ll do.
>
> Cheers,
> Rob
>
>   *From:* David Mertens <dcmertens.p...@gmail.com>
> *Sent:* Monday, May 25, 2015 9:35 PM
> *To:* Sisyphus <sisyph...@optusnet.com.au>
> *Cc:* Chris Marshall <devel.chm...@gmail.com> ;
> pdl-devel@lists.sourceforge.net
> *Subject:* Re: [Pdl-devel] Insert C code before '#include "EXTERN.h"'
>   But aren't there basic ways to work around this? Why don't they prefix
> all struct declarations with something like proj_ or libproj_? They could
> then include #defines that provide like-named symbols without the prefix
> UNLESS you have #defined some sensibly named symbol, like
> PROJ_NO_NAMESPACE_POLUTION. This keeps the behavior backward compatible,
> but solves your problem. They don't even need to do it for all tokens, just
> the ones that give trouble, at least for starters.
>
> Hrmph.
> David
>
> On Thu, May 21, 2015 at 6:19 AM, <sisyph...@optusnet.com.au> wrote:
>
>>
>> From: Chris Marshall
>> Sent: Thursday, May 21, 2015 3:24 AM
>> To: Sisyphus
>> Cc: pdl-devel@lists.sourceforge.net
>> Subject: Re: [Pdl-devel] Insert C code before '#include "EXTERN.h"'
>>
>> > It's a hack but what about adding -D_PROVIDER_STRUCTS_DEFINED to the
>> > DEFINE?
>>
>> Yes, that does the trick - and allows me to verify that it doesn't have
>> the
>> effect I hoped it would have.
>>
>> There's a problem with PDL::GIS::Proj that arises because the proj header
>> projects.h introduces a symbol named PVALUE. Unfortunately a symbol of the
>> same name has already been introduced in winreg.h.
>>
>> I've been working around this problem by hacking the proj code prior to
>> building the library, so that "PVALUE" is replaced by a symbol that
>> doesn't
>> clash.
>> It's a pita, and I'm looking for a better solution - but defining
>> _PROVIDER_STRUCTS_DEFINED is not it.
>>
>> Best solution would be if the proj developers renamed "PVALUE" to
>> something
>> that doesn't clash - but they're not entirely thrilled at that prospect,
>> given that projects.h is public (to some extent, at least).
>>
>> Cheers,
>> Rob
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> pdl-devel mailing list
>> pdl-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>>
>
>
>
> --
> "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Reply via email to