Andrew Ross writes: > I am aware of this. I posted a proposal to fix this some weeks back > for comment, but got no feedback. To my mind.
Sorry I missed that. > 1) plplot is broken in making some of these things visible to users. > 2) python is also broken for the same reason. Emphatically agree on both points. > Technically this is akin to an API change since some of these symbols > have been visible for a long time (pre cmake I think) and so some > users might rely on then. This is what I wanted feedback on. Mmmm. I'm a big fan of backward compatibility, but I feel stronger about advertised features than about unadvertised misfeatures. To me, this HAVE_* stuff, leaking out into the global namespace, by both PLplot and Python, is a very annoying misfeature in both systems. I have scads of warnigs coming out in every compile from this. > On Fri, Jun 19, 2009 at 12:23:45AM -0500, Geoffrey Furnish wrote: > > I can confirm that use of PLplot together with the Python C API, > > produces many many warnings, some of them traceable to the HAVE_* > > business. I plan to try to clean this up sometime soon. Andrew Ross writes: > On Tue, Jun 23, 2009 at 02:31:08PM +0300, Dmitri Gribenko wrote: > > On Tue, Jun 23, 2009 at 11:28 AM, Andrew > > Ross<[email protected]> wrote: > > > Technically this is akin to an API change since some of these symbols > > > have been visible for a long time (pre cmake I think) and so some > > > users might rely on then. This is what I wanted feedback on. > > > > We could still install plConfig.h but remove all references to it from > > user-visible headers. Thus users who rely on it could include it > > themselves. > > > > Also, it would be better to hide all internal declarations altogether. > > It could be easily done like this: in all sources we define a macro, say > > IN_PLPLOT_CORE and check for it in all headers. All internal stuff in > > headers should be guarded #if IN_PLPLOT_CODE ... #endif. The macro can > > be defined on the command-line of compiler, -DIN_PLPLOT_CORE=1, so only > > modifications to headers is necessary. > > This still doesn't get round the problem of python leaking these > declarations. For that we would have to rename the declarations to > something like PLPLOT_HAVE_ISINF. Yes, that's a good idea. I'm also trying to work up to just sending in a patch for Python, but I haven't gotten to it yet. Even so, that would only at best show up in some future Python, and I'll spend years dealing with the warnings flowing out of 2.6.x. So, I see considerable merit in what you're proposing. ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
