The filename fix has been committed to the hdf5 repo in the "branches/hdf5_1_10_0" location. This branch aligns with the 1.10.0-patch1 release.
We will let everyone know when the hdf5_1_10 branch is available later. Allen On Wednesday, June 08, 2016 05:51:44 PM Elena Pourmal wrote: > Roger and all, > > You can access HDF5 source (trunk, branches, tags, etc.) using SVN at > https://svn.hdfgroup.org/hdf5 > > We are switching to Bitbucket; it will be public after the HDF5 1.10.1 > release later this summer. > > > Roger, > > Allen will let you know when the typo fix is in. > > Thank you for reporting the problem! > > Elena > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Elena Pourmal The HDF Group http://hdfgroup.org > 1800 So. Oak St., Suite 203, Champaign IL 61820 > 217.531.6112 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > On Jun 8, 2016, at 8:21 AM, Roger Leigh > <[email protected]<mailto:[email protected]>> wrote: > > Thanks. Is there a commit for that I could cherry-pick, or a diff I > could pick up in the interim? > > Regarding the command length overflow on Windows and Linux, I've had a > look and it's due to the amount of POST_BUILD custom commands which are > being created. These are concatenated into a single mega-command, which > exceeds the OS argv limits. The attached patch reduces it sufficiently > by converting these into regular dependencies and targets to alleviate > the problem, so they are then regular separate dependency-driven > actions, but likely needs doing across the board--it's not intended to > apply right now but rather to demonstrate a possible solution. I'd be > happy to work on a more comprehensive solution by extending this to all > custom command usage if that's useful to you. > > With this patch, I can use the Ninja generator on Windows. There are > some unrelated failures I still need to investigate which I'll follow up > with separately. > > If the test data is modified by the tests and needs re-copying, then > this strategy won't be sufficient on its own. But ctest runs appear to > be idempotent, so this doesn't look like an issue. If it is, then we > could do the copying in a test wrapper (see below). > > > Could I possibly also point you to this example: > > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/bzip2/patc > hes/cmake.diff#L205 > > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/bzip2/patc > hes/cmake.diff#L226 This is a wrapper to run tests, which resolves all the > needed run-time paths via cmake generator expressions, and which makes the > tests > completely generator-agnostic and work across the board on Windows. A > similar test wrapper could be written for hdf5, with a hdf5_add_test > around add_test to make use of it. Again, I'd be happy to look into > doing this if you'd find this useful. > > > Is hdf5 in a public VCS? I couldn't see it on your github HDFGroup > group, unless I overlooked it or it's under a different name? > > > Kind regards, > Roger > > On 07/06/2016 18:05, Allen Byrne wrote: > There is a typo in the CMake test call - it should be using the "latest" > version of the hdf5 file. This will be fixed in the next release of 1.10. > > Allen _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
