On 09/17/2010 03:04 AM, Eric Firing wrote:
> On 09/16/2010 09:27 PM, Jason Grout wrote:
>>
>>
>> I see the change that you made (keep the old order for linux, do the new
>> thing for everything else).  This seems like a bad thing to do.  Looking
>> at setjmp.h, it includes features.h.  features.h relies on the POSIX and
>> XOPEN variables that are defined in Python.h to set up the environment,
>> and the actions from setjmp.h depend on that environment.  I think the
>> warning from the Python docs (if I read correctly) is that the
>> environment must be set up according to the requirements, and Python.h
>> sets up those requirements.  In other words, by undefining the POSIX and
>> XOPEN variables, it seems you have a very real likelihood of including a
>> different setjmp.h in the Python.h compared to the libpng (because the
>> conditions set up by features.h may be different).
> Before making that change, I verified that at least on my linux system,
> Python.h defines those two variables the same way that features.h does,
> so the redefinition would be harmless if we did not undefine the
> variables. I don't think we are any worse off than before with respect
> to linux, and we should be better off with respect to other
> platforms--mpl on Solaris now compiles, right?.  But I am certainly
> still not comfortable with the whole setjmp mess.  I would love to see
> someone come up with a clean, clearly understandable solution, and
> resolve it once and for all.

Okay, I'm glad you checked on your box.  I agree that we wouldn't be any 
worse than before.  Hopefully everyone's feature.h defaults are the same 
as what Python assumes.  And hopefully Python hasn't changed those 
definitions over the supported releases.

However, wouldn't it be good to leave the redefinitions in, though?  
They are warnings (and they are not spurious), and that would remind us 
that we should investigate the situation in the future (maybe after we 
stop supporting old versions of libpng).  At least on your system, the 
redefinition would not change anything.  I would prefer a warning 
reminding me of an ugly situation that could really potentially be a 
problem, rather than a hack to disable the warning because it doesn't 
affect a particular system or two.

Thanks,

Jason


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to