Hi Allen, I would vote for supporting only cmake-build zlb, otherwise you will need to handle a lot of complexity, as there are numerous custom built zlib binaries hanging around the internet. Of course, this treatment will disable them, but IMO it is not unrealistic to assume that if someone builds hdf5 using cmake he can also build zlib the same way. Then my proposed modification amounts to 1) simply using hardcoded names zlib.lib and zlib1.dll (if shared version requested) instead of variables 2) copying the right dll from the right source configuration to the right target configuration.
I have meanwhile also identified a problem in zlib's CMakeLists that the build using the static configuration fails. Have reported to the authors. So the must for the dynamic configuration brings me to configure hdf5 as a shared lib, thus hitting this problem. Best regards, Dominik On Wed, Mar 2, 2011 at 4:03 PM, Allen D Byrne <[email protected]> wrote: > Dominik, > > OK, I understand the problem now. Yes, the existing zlib distribution does > have some issues. I use newly built versions of zlib that fixes that > problem. In fact, I have new zlib CMake files under development (still > testing and fixing issues) that I hope will be ready for the 1.8.7 release. > Please note that I have made significant changes to the CPack commands in > the HDF5 CMakeLists.txt files. These changes will improve the packaging and > work better with FindHDF5.cmake modules in projects that use HDF. > > Having said all that, I would like to look at your patch and compare. Next > week, I will be updating the 1.8 branch on our svn with some significant > CMake changes, please take a look - I am open to improvements! > > Allen > >> The guilty part in the makefile: > >> > >> GET_FILENAME_COMPONENT(ZLIB_DLL_NAME ${ZLIB_LIBRARY} NAME_WE) > >> > >> This does not work as the lib and dll have different names when the > >> official zlib source is compiled, at least on MSVC2010/64. > >> If you only want to support a cmake-built zlib then it should be > >> renamed to zlib1.dll. If support for an arbitrary zlib build is > >> required I propose to use a separate variable for the lib and dll and > >> have the user provide both. > >> Or eliminate copying completely, just informing the user to do it. The > >> latter would have the benefit of copying zlib dlls from proper > >> configuration build folders (not just one fixed for all). > >> > >> If there is any interest, I can provide a patch. > >> > >> Dominik > >> > >> > >> On Wed, Mar 2, 2011 at 1:02 PM, Dominik Szczerba <[email protected]> >> wrote: > >> > 1> Copying C:/build/zlib-1.2.5/RelWithDebInfo/zlib.dll to > >> > C:/build/hdf5-1.8.6/bin/RelWithDebInfo/ > >> > 1> Error copying file (if different) from > >> > "C:/build/zlib-1.2.5/RelWithDebInfo/zlib.dll" to > >> > "C:/build/hdf5-1.8.6/bin/RelWithDebInfo/". > >> > 1>C:\Program Files > >> > (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): > >> > error MSB6006: "cmd.exe" exited with code 1. > >> > 1> > >> > 1>Build FAILED. > >> > > >> > > >> > The one created by zlib is called zlib1.dll (lib file still called >> > zlib.lib) > >> > > >> > >> _______________________________________________ > >> 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
