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

[netCDF #TWS-325985]: nf-config / netcdf-fortran.pc issues



> Thanks for the heads up on the --has-f03 option.
> 
> Yeah, I couldn't decide whether having only nf-config --libs (you are already
> asking for fortran by calling nf-config) or nf-config --flibs supported made
> more sense.  I guess nc-config uses --flibs already so perhaps just go with 
> that.

OK, I'll do that and see if I get any objections.

> I also carry a patch in Fedora to have nf-config --flibs call pkg-config
> netcdf-fortran --libs.  This is to avoid having /usr/lib , /usr/lib64 paths
> encoded in /usr/bin/nf-config depending on architecture which breaks having
> both 32 and 64 bit development libraries installed on the same machine.  I'll
> let you decide if you want to go that route as well.

I'm hesitant to add a dependency on pkg-config, because I don't know whether 
it's
always available on various Unix platforms.  In particular, according to 

  http://cairographics.org/end_to_end_build_for_mac_os_x/

that developer includes the source for a recent version of pkg-config with the 
distribution, giving this reason:

  Why pkg-config? Pkg-config is a package configuration management
  tool. OSX comes with one, but it's very old and the Cairo build
  system wants a newer one. You may have a new one via something like
  macports, but we don't want some of the other macports derived
  pkg-config dependencies. Building our own keeps the build nice and
  isolated.

So it's a tradeoff between adding another dependency versus breaking 
environments with both 32-bit and 64-bit development libraries.  Do 
you have any advice about that?

--Russ

> On 04/07/2013 02:01 PM, Unidata netCDF Support wrote:
> > Hi Orion,
> >
> > Thanks, I committed your patches plus added --has-f03 to nf-config
> > options to indicate when the Fortran-2003 interoperability feature was
> > used to support the f90 API.  Without this, the --has-f90=no seems to
> > indicate that the F90 API is not supported, which is not he case when the
> > Fortran-2003 build was used.
> >
> > As for the last issue you raised, I'm thinking it would be best to just have
> > --flibs and delete --libs from the nf-config options to avoid the
> > confusion.  However, I haven't done that yet ...
> >
> > --Russ
> >
> >> A couple of related issues with nf-config and netcdf-fortran.pc:
> >>
> >> - For static linking, netcdf-fortran.pc should provide:
> >>
> >> Libs.private: -L${libdir} -lnetcdff -lnetcdf
> >>
> >> - nf-config --flags should not return the compiler flags used to compile
> >> netcdf-fortran.  On Fedora for example, all kinds of extra flags are
> >> added that end-users may or may not want.
> >>
> >> - Having nf-config have both a --libs and a --flibs options seems
> >> confusing, especially with nf-config --libs returning -lnetcdf.  Not
> >> sure the best way forward on this though.
> >>
> >> I've attached a patch for the first two changes.
> >>
> >> --
> >> Orion Poplawski
> >> Technical Manager                     303-415-9701 x222
> >> NWRA/CoRA Division                    FAX: 303-415-9702
> >> 3380 Mitchell Lane                  address@hidden
> >> Boulder, CO 80301              http://www.cora.nwra.com
> >>
> >>
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: TWS-325985
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> 
> 
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
> 3380 Mitchell Lane                       address@hidden
> Boulder, CO 80301                   http://www.nwra.com
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: TWS-325985
Department: Support netCDF
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.