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

Re: 20040628: netcdf installation minor issue (fwd)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20040628: netcdf installation minor issue (fwd)
  • Date: Mon, 28 Jun 2004 18:39:55 -0600
------- Forwarded Message

Date:    28 Jun 2004 17:03:24 -0600
From:    Ed Hartnett <address@hidden>
To:      address@hidden
cc:      Russ Rew <address@hidden>
Subject: Re: 20040628: netcdf installation minor issue (fwd)

> >To: address@hidden
> >From: der Mouse <address@hidden>
> >Subject: netcdf installation minor issue
> >Organization: ?
> >Keywords: 200406281925.i5SJPZWb016557 netCDF configure
> 
> I'm working with NetCDF 3.5.1, and I notice that the installation step
> uses the --prefix= value from configure, but, unlike most
> configure-driven installations, it insists on putting everything under
> a single directory, rather than allowing --bindir=, --libdir=, etc, to
> override the default directories individually.  Is there any particular
> reason why macros.make.in says
> 
> # Installation Directories:
> SRCDIR                = @SRCDIR@
> prefix                = @prefix@
> exec_prefix   = $(prefix)
> INCDIR                = $(exec_prefix)/include
> LIBDIR                = $(exec_prefix)/lib
> BINDIR                = $(exec_prefix)/bin
> MANDIR                = $(prefix)/man
> 
> rather than
> 
> # Installation Directories:
> SRCDIR                = @SRCDIR@
> prefix                = @prefix@
> exec_prefix   = @exec_prefix@
> INCDIR                = @includedir@
> LIBDIR                = @libdir@
> BINDIR                = @bindir@
> MANDIR                = @mandir@
> 
> (which would permit individual overrides)?
> 
> For me personally, it's not that big a deal; I'll just add code to my
> build script to fix up the directories after running configure (in the
> setup I'm trying to install it in, having all those directories being
> siblings of one another is not acceptable).  But it's an annoyance, and
> as far as I can tell, an unnecessary annoyance.


Howdy!

We are planning a 3.7.0 release in October which will include a
complete refactoring of the configure and install steps, including the
use of a more standard directory structure and support for the
overrides as is usual.

Thanks,

Ed Hartnett
Unidata

------- End of Forwarded Message