Hi,
Dropping use of the "--with-..." syntax to specify where configure
should find installed libraries was intended to fix a couple of serious
bugs in building netCDF, as described here:
https://www.unidata.ucar.edu/jira/browse/NCF-20
I also wondered why we couldn't at least provide an error message when
"--with-hdf5=..." was given as a configure option, because we do provide
an error message for unsupported options such as "--tooth-fairy".
However, that would actually violate an autoconf rule:
Sorry, but --with-XXX= options must not be error'd out, as an autoconf
convention. Some other organization might well create a configure
which includes netcdf, as well as some other package that
(coincidentally) uses --with-hdf5=. In this case, if we error'd out,
that would break a configure which would otherwise be expected to
work.
So although --tooth-fairy will fail, --with-anything will not, because
configure will assume that you wish to pass it to another configure
running as a subconfigure.
Autoconf moves in a mysterious ways, its wonders to perform.
We're sorry for the problems caused by changing the way the library is
built, but the motivation was fixing bugs rather than making it more
convenient for us. The support questions about this issue have
definitely made more work for us ... :-)
Ed may have more to say about this when he's back at his keyboard.
--Russ
> I have to admit that I too wax nostalgic for the --with-hdf5 days. (I
> still haven't been able to get 4.1.3-beta1 to build, so I'm sticking
> with 4.1.1 for the foreseeable future.)
>
> On Aug 2, 2011, at 12:43 PM, Jennifer Adams wrote:
>
> > I agree with everything in this post, building 4.1.3 has become a
> > gigantic pain. And I didn't look in the release notes to see that the
> > --with-hdf5 option had been eliminated and was baffled by why all the
> > configure test programs were having trouble finding my hdf5 and szip
> > builds. Now I have read the release notes and I see you are passing
> > your pain onto your users. Humph! There ought to be a warning right at
> > the beginning of the configure script, when it parses the args and
> > switches, and also in the --help output if possible. I see the new
> > configure setup as being broken because of all the flags that need to
> > be set/unset, which is not the way it should be -- none of the other
> > 25 libraries I have to build for GrADS work this way. What is the
> > presumed standard way of finding libraries? Please add some
> > documentation with guidance for the best way to proceed without the
> > --with-hdf5 (et al.) options. Does hdf5 library need a hdf5-config
> > file or a pkgconfig file? Should we lobby the HDF Group to implement
> > such a thing, because this new set up is really awful.
> > --Jennifer
> >
> >
> > On Aug 2, 2011, at 11:07 AM, Fabr=EDcio Zimmerer Murta wrote:
> >
> >> I've just read in the NetCDF's release notes the following, for
> >> the 4.1.3-beta1 version from 2011-04-29:
> >>
> >> "Took out --with-hdf5 and related options due to high
> >> cost of maintaining this non-standard way of finding
> >> libraries."
> >>
> >> Now, to the facts:
> >> 1. this option forces people with custom HDF5 libraries to manually
> >> change CFLAGS, FCFLAGS and LDFLAGS in compile time.
> >> 2. NetCDF 4.1.3 requires HDF5 1.8.6
> >> 3. Current linux distros comes with just HDF5 1.8.4
> >>
> >> Result: You removed the option to select HDF libraries when it would
> >> be most needed as everyone is needing to install custom HDF5 library
> >> on their computer. This makes people lifes a lot harder, you know? I
> >> am planning on shipping NetCDF and HDF5 as nested packages with a
> >> project we are doing due to excessive compile problems, and we will
> >> be forced to add back AC_WITH_ARG for HDF5 in NetCDF provided
> >> package, in order for it to work in accordance with the main
> >> package's arguments.
> >>
> >> And, why did you call the AC_ARG_WITH option a non-standard way to
> >> find libraries? I thought it was a standartizing attempt from GNU
> >> autotools to aid in linking to packages...
> >>
> >> - fabricio
> >>
>
> --
> Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
