[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #IQO-210917]: Fortran 90 manpages missing in netcdf 3.6.2 beta3

> Hi again Ed,
> 
> >
> 
> That is right, but "configure" will tell if the F77 and/or F90
> compilers are set up. If not, no fortran code will enter the netcdf
> share library in the first place. So when compiling from scratch
> there should not be an issue. Distributing binaries with or without
> F77/F90 support is the only thing that becomes more complex.

The problem is when there *is* f90 on the machine. In that case, even a C-only 
program will not build and run for me without being able to find the F90 
libraries.

> 
> >
> > Do you think this is a bad idea? Would you like to try getting the
> > combined shared
> > library working? It is easy to change the configure script, but
> > then the build breaks for me.
> 
> As said, I'm now convinced that for the time being (probably until
> GCC 4.1 or 4.2 comes with gfortran standard built in, it is wiser to
> keep the fortran shared library separate. Just to make the transfer
> of binaries easier, and probably shortening the loading time of C-
> only programs that call the netcdf shared library.

I am using gcc 4.1, which comes with gfortran. But this is not the only fortran 
compiler we have to support.

> 
> > Any thoughts would be most welcome. This is our first release with
> > shared library support so we are feeling our way forward carefully
> > and would welcome
> > any informed input.
> >
> > Do you use shared libraries a lot? If so, why?
> 
> Yes, I use shared libraries a lot. I've been doing so ever since I
> worked on an RS6000 that had that capability about 10 years ago. It
> makes the binary executables SO much smaller. I've been making shared
> libraries whenever I could since then on Linux and now on Mac OS X.
> As a developer for GMT (Generic Mapping Tools), I've been working to
> get the shared library support for Mac OS X in there too. GMT has
> some libraries of its own and uses netCDF in all its ~50 programs.
> You can imagine that the duplication of binary code gets tremendous
> when you are creating a package with that many programs.
> 

Thanks.

> > Incidently, some of the docs have been updated, but until the next
> > beta release you
> > would have to do "./configure --enable-docs && make" to build it,
> > and it will only work if you have a recent texinfo and tex
> > installation, and tex is somewhat weird - it works
> > for me on some machines but not others.
> 
> It works for me on Mac OS X without a problem. But keep packaging
> WITH the pdf files in there, since not everybody will have TeX set up
> on their computers.
> 

Yes, that is the intention.

> >
> > However, you can give it a try, and if it works you will find the
> > latest documentation
> > in the man directory, as text, pdf, info files, web pages, etc.
> >
> >>
> >> 2) In all the manuals, after netcdf calls there is:
> >>
> >> if (status.ne.nf_noerr) call handle_err(status)     ... or similar in
> >> case of C and F90
> >>
> >> However, handle_err(status) already checks against nf_noerr, so the
> >> if-statement is superfluous.
> >> It would be much cleaner simply to write after the netcdf calls:
> >>
> >> call handle_err(status)
> >>
> >> In fact, I use a short-cut to that and use, for example:
> >>
> >> call handle_err(nf_close(ncid))
> >>
> >> Just a suggestion. But I think a useful one.
> >
> > Thanks, I will pass that on to the author of that code and see what
> > he thinks.
> >
> > Where are you finding the handle_err() funtion anyway?
> 
> It is not in the distro, but it is spelled out earlier on in each of
> the manuals. For example, in the F77 manual:
> 
> SUBROUTINE HANDLE_ERR(STATUS)
> INTEGER STATUS
> IF (STATUS .NE. NF_NOERR) THEN
> PRINT *, NF_STRERROR(STATUS)
> STOP ’Stopped’
> ENDIF
> END
> 

Yes, I found this (and added it to the index in all documents, to make it 
easier to find next time.

> You see there's the status check in there already. Similar in the C
> and F90 manuals. So all the error checks mentioned in the rest of the
> examples in the manuals can be dropped.
>
 
I will send Russ's answer via email.
> 
> >
> > Thanks again for looking at my beta!
> >
> > I am also looking into the problem of the man pages and where they
> > end up, but haven't
> > found a solution yet. Thanks for pointing out the problem.
> 
> Yes, I thought it would not be easy. I just wrote a Fink script that
> simply copies the stuff in place after a "make install-strip".
> 
> By the way, I noticed that "make install" does not descend into the
> man/ directory to install the manuals and/or the docs. That's fine
> with me, but there is no target install-man (in the main Makefile)
> which should do the job. And there is no install-doc (or similar)
> target that just installs (but not makes) the netcdf*.pdf manuals.
> 

Yes, this is the very problem I noticed yesterday.

Thanks,

Ed

Ticket Details
===================
Ticket ID: IQO-210917
Department: Support netCDF
Priority: Normal
Status: Closed