Let me try to explain some more because I was the one who added the
H5_BUILT_AS_DYNAMIC_LIB variable. The reason this variable was needed
was because projects that _use_ HDF5 and want to deploy their
application to another machine need some sort of mechanism to
correctly determine if the HDF5 project was built as a static or
dynamic library. Using file extensions and other filenaming schemes
are NOT good enough as someone could change the file names. This is a
problem on Windows as there is NO set naming convention for libraries
and no direction from Microsoft so really anything goes. When HDF5 is
built using CMake this variable is written into another header file
(H5pubconf.h) which is then pulled in by another header (H5public.h).
So start with H5Public.h file. This FIRST includes the H5pubconf.h
file which is generated by CMake or autotools. Within H5pubconf.h the
H5_BUILT_AS_DYNAMIC_LIB is either defined to 1 or NOT defined at all
based on how HDF5 is being built. Further down in H5Public.h is the
#include "H5api_adpt.h" which brings in all the Windows DLL defines
that are needed in order to correctly export the functions in HDF5
library when compiling on windows (and to some extend GCC). If you
follow this flow then you will see that there is NO need to define
H5_BUILT_AS_DYNAMIC_LIB yourself in ANY project. And in fact doing so
may create problems for your project.
Actually the use of _HDF5USEDLL_ can actually be completely gotten
rid of in the Visual Studio projects with some fixes to the current
logic that is contained in the preprocessor blocks. I think at one
point I had a patch that got rid of it but it never got picked up.
http://www.cmake.org/Wiki/BuildingWinDLL may provide some more
background information but is CMake specific.
Hope that helps explains things.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer [email protected]
BlueQuartz Software Dayton, Ohio
On Nov 12, 2010, at 10:21 AM, Allen D Byrne wrote:
As Elena mentioned, that was an error in the comments. It should
have been something like the following:
The Visual Studio project files be not be supported in the next
major release of 1.10
As far as :
> So what, if any, are the functional consequences to VS2005
projects client
> code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h,
lib binary
> deliverable - bearing in mind that my application is built,
tested, and
> seems to be working fine....?
Building applications using the dynamic libs/dlls means you will be
importing the libraries and defining just H5_BUILT_AS_DYNAMIC_LIB
will bypass all the exports blocks arriving at lines 87,88:
#define H5_DLL __declspec(dllimport)
#define H5_DLLVAR __declspec(dllimport)
Similiarly, all the other defines will be imports.
Not defining H5_BUILT_AS_DYNAMIC_LIB will skip to the else block at
line 290:
#if defined(_WIN32)
which then will check the existence/value of the original defines to
set each of the defines mentioned previously.
--- So that if _HDF5DLL_ is not defined and _HDF5USEDLL_ is defined
- lines 297,298:
#define H5_DLL __declspec(dllimport)
#define H5_DLLVAR __declspec(dllimport)
and similiarly the other defines will check for 'USE' defines to set
the the other defines.
NOTE: if neither _HDF5DLL_ or _HDF5USEDLL_ is defined, then the
defines will be set at lines 300,301:
#define H5_DLL
#define H5_DLLVAR extern
Which may cause problems! Therefore because you have defined
H5_BUILT_AS_DYNAMIC_LIB, you have set all defines to
__declspec(dllimport) and can ignore worying about all the 'USE'
defines.
Allen
>
> Hi All.
> My reason for setting H5_BUILT_AS_DYNAMIC_LIB is based on the fact
that
> 1) h5api_adpt.h uses it as a #ifdef switch to define H5_DLLVAR,
> 2) AND, the #else branch of this (which references the
_HDF5USEDLL_ ifdef)
> is very clearly marked thus in the comments:
>
> /* This is the original HDFGroup defined preprocessor code which
should
> still work
> * with the VS projects that are maintained by "The HDF Group"
> * This will be removed after the next release.
> */
>
>
> The statement "this will be removed in the next release" led me to
assume
> that this section of the header is deprecated and should not be
used in new
> code, and hence that the best define to use would be
> H5_BUILT_AS_DYNAMIC_LIB.
>
> Is this interpretation incorrect - will this section of the header
continue
> to exist in future?
>
> I don't use CMake, and I'm not building HDF5, just using it from
my client
> code.
> So what, if any, are the functional consequences to VS2005
projects client
> code defining H5_BUILT_AS_DYNAMIC_LIB and building against the h,
lib binary
> deliverable - bearing in mind that my application is built,
tested, and
> seems to be working fine....?
> Steve
>
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
