Relying on someone else NOT to rename the libraries because they monkey around with the CMake files probably isn't a good option either. If you ask "how are libraries named on Windows" you will get at least 2 different answers (most likely more). With mingw they are .dylib, with msvc they should be .dll. But where are the "Runtime" libraries installed versus the link time libraries? some install them into lib some install them into bin. Some install in both places. I got tired of trying to out-think the other person and just added those symbols to the header. I have my own "FindHDF5.cmake" that looks specifically for those symbols during my project's configure process then can make smarter decisions based on what it finds.
Still confused on the "... creating other folders." What other folders are getting created? I don't have a problem with moving the build specific defines somewhere out of H5pubconf.h. Just let me know where you want them. I guess I'll add the necessary version checking code to my own project to know that if we are HDF5 1.8.10 or less I look in a certain header otherwise look in another place. Having that define in there solves a lot of deployment problems for windows and to some extent OS X. Thanks ___________________________________________________________ Mike Jackson Principal Software Engineer BlueQuartz Software Dayton, Ohio [email protected] www.bluequartz.net On Nov 20, 2012, at 3:41 PM, Allen D Byrne wrote: > Mike, > > Sorry didn't mean to confuse - debug/release - I was thinking globally about > the issue, obviously these defines have nothing to do with debug/release > other > then creating another set of folders. The find_package would happen after > hdf5 > is installed and using cmake to read the hdf5 cmake configuration. > > I was hoping to remove the build specific defines in H5pubconf.h to somewhere > else, because these defines are the only difference between static/dynamic > installs. Libraries are named unique enough. > > Of course thinking about it now, there are other optional components in > H5pubconf.h! (szip/zlib/parallel...) > > Allen > > On Tuesday, November 20, 2012 03:27:16 PM Michael Jackson wrote: >> Which "FIND_PACKAGE" sets that variable? >> >> Inside of the Top level CMakeLists.txt file I have this now. >> >> OPTION (BUILD_SHARED_LIBS "Build Shared Libraries" OFF) >> set(H5_BUILT_AS_DYNAMIC_LIB 0) >> set(H5_BUILT_AS_STATIC_LIB 1) >> SET (LIB_TYPE STATIC) >> SET (H5_ENABLE_SHARED_LIB NO) >> SET (H5_ENABLE_STATIC_LIB NO) >> IF (BUILD_SHARED_LIBS) >> SET (LIB_TYPE SHARED) >> ADD_DEFINITIONS (-DH5_BUILT_AS_DYNAMIC_LIB) >> set(H5_BUILT_AS_DYNAMIC_LIB 1) >> set(H5_BUILT_AS_STATIC_LIB 0) >> SET (H5_ENABLE_SHARED_LIB YES) >> ELSE (BUILD_SHARED_LIBS) >> ADD_DEFINITIONS (-DH5_BUILT_AS_STATIC_LIB) >> set(H5_BUILT_AS_DYNAMIC_LIB 0) >> set(H5_BUILT_AS_STATIC_LIB 1) >> SET (H5_ENABLE_STATIC_LIB YES) >> IF (NOT WIN32) >> # should this be a user setting : Everyone uses it anyway ? >> ADD_DEFINITIONS (-DPIC) >> ENDIF (NOT WIN32) >> ENDIF (BUILD_SHARED_LIBS) >> >> >> Then in config/cmake/H5pubconf.h.in I added the following: >> >> /* Defined if HDF5 was built with CMake AND build as a shared library */ >> #cmakedefine H5_BUILT_AS_DYNAMIC_LIB @H5_BUILT_AS_DYNAMIC_LIB@ >> >> /* Defined if HDF5 was built with CMake AND build as a static library */ >> #cmakedefine H5_BUILT_AS_STATIC_LIB @H5_BUILT_AS_STATIC_LIB@ >> >> Which now allows everything to work. I am still confused why the change was >> needed for Debug/Release? Ironically enough I'm the original person to put >> the H5_BUILT_AS_DYNAMIC_LIB flag in the header file because when on windows >> and using CMake in another project that includes HDF5 I needed to be able >> to better figure out how the libraries were built so I could make decisions >> on what needs to be copied into my deployment package. >> >> ___________________________________________________________ >> Mike Jackson Principal Software Engineer >> BlueQuartz Software Dayton, Ohio >> [email protected] www.bluequartz.net >> >> On Nov 20, 2012, at 2:36 PM, Allen D Byrne wrote: >>> The problem was that I attempted to allow multiple installs >>> (debug/release, >>> static/dynamic) of hdf5. Everything works great with cmake, because the >>> value is set by the FIND_PACKAGE command. However, I failed to account >>> for the non- cmake process. I wanted to eliminate the duplicate include >>> folders that would result from multiple installs. >>> >>> What to do with that definition is the issue! >>> >>> Allen >>> >>> On Tuesday, November 20, 2012 02:04:21 PM Michael Jackson wrote: >>>> Hmm >>>> >>>> Looking at the H5pubconf.h for the 1.8.9 and 1.8.10 builds it would seem >>>> >>>> that there were some merge issues maybe? Otherwise why was that >>>> definition >>>> removed? Not that I run the tests much (I assume if HDF5 is release then >>>> all the tests are passing but how would any of the tests run if nothing >>>> to >>>> can correctly? Odd. Let me take a look. Can we get this into the first >>>> patch release if I figure out what went wrong? >>>> ___________________________________________________________ >>>> Mike Jackson Principal Software Engineer >>>> BlueQuartz Software Dayton, Ohio >>>> [email protected] www.bluequartz.net >>>> >>>> On Nov 20, 2012, at 1:56 PM, Allen D Byrne wrote: >>>>> Mike, >>>>> >>>>> Are you using CMake to create the hdf5 library? There is an issue with a >>>>> definition that needs to be solved for the next release (the pre-built >>>>> binaries have this define in the H5pubconf.h). >>>>> Add >>>>> >>>>> #define H5_BUILT_AS_DYNAMIC_LIB 1 >>>>> >>>>> in your H5pubconf.h file after building HDF5. >>>>> >>>>> Allen > _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
