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
