On Tue, Sep 15, 2009 at 11:47:53AM -0700, Alan Irwin wrote:
> Hi Werner:
>
> This is mostly directed to you, but there is also a quick question for Andrew
> about the java bindings in my comments below.
>
> On 2009-09-15 15:34+0200 Werner Smekal wrote:
>
>> Hi Alan,
>>
>> I added these redefinition macros to plcdemos.h and plc++demos.h. But
>> since we already use such a macro for isnan(), where PL__HAVE_ISNAN is
>> defined in plConfig.h, I decided to do the same as well for _snprintf.
>> So I copied the relevant part form config.h.cmake to plConfig.h.cmake
>> and all works again for Visual C++.
>
> I far prefer your idea (using configured macros for PL_HAVE_SNPRINTF and
> _PL_HAVE_SNPRINTF in plConfig.h) to mine (configuring those same macros in
> plcdemos.h and plc++demos.h). I had forgotten that plConfig.h was already
> #included by plcdemos.h and plc++demos.h. Anyhow, like what you have done
> subject to the duplicate macros issue (see below).
>
> N.B. I hope you or somebody else will follow up and replace sprintf by
> snprintf throughout the C and C++ examples (to demonstrate our good practice
> for those examples and to inspire users to use snprintf as well for their
> own PLplot applications).
>
>> Actually, why do we have config.h and plConfig.h, where the latter
>> seems to be a subset of the first?
>
> Before answering that important question I would like to give some
> background for those here who are not aware of it.
>
> The purpose of config.h is to contain all the configured macro dreck that is
> required in the core build but which we don't want to expose for example
> builds and user application builds. The purpose of plConfig.h is to contain
> the minimal set of configured macros that you do need to expose for example
> builds and user application builds. The way the build system implements this
> separation between the two sets of configured macros in config.h and
> plConfig.h is via HAVE_CONFIG_H. That is just #defined (see
>
> ADD_DEFINITIONS("-DHAVE_CONFIG_H")
>
> in the top-level CMakeLists.txt file) for the core build of PLplot, but
> not for the build of the examples (see
>
> remove_definitions("-DHAVE_CONFIG_H")
>
> in examples/CMakeLists.txt (as of revision 10413).
>
> As of revision 10412 I have documented the different purposes of
> config.h.cmake and plConfig.h.cmake in those files, and because there is
> obviously no need of duplicate macros (in answer to your question) I have
> removed all such duplicates from config.h.cmake.
>
> Revision 10413 gives me good results for a (rather) complete core build
> (including build-tree examples) and separate installed examples build, but
> others should test that revision 10413 as well to make sure that change to
> no duplication between config.h and plConfig.h introduces no build errors
> for their particular configuration/platform.
>
> FOR Andrew: There is one other place in our build system
> 'remove_definitions("-DHAVE_CONFIG_H")' occurs and that is in
> bindings/java/CMakeLIsts.txt. I don't know the purpose of that or even
> whether it is necessary. Andrew, do you remember? Anyhow, for now I am
> leaving it because it appears to work okay for the test mentioned above.
Firstly, sorry for the silence over the last few weeks. I have been away
with work. I hoped to have email access but it didn't work out.
I don't recall. I think it was copied from somewhere else. It is possible
that config.h interferes with some of the C swig generated files, but it
seems unlikely.
Andrew
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
