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

: 20010826: netCDF install rules

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: : 20010826: netCDF install rules
  • Date: Mon, 27 Aug 2001 10:04:05 -0600
Steve,

> >From: "Steve M. Robbins" <address@hidden>
> >Subject: install rules
> >Organization: Videotron/Canada
> >Keywords: 200108262020.f7QKKM117586 netCDF install

The above message contained the following:

> During a debugging session yesterday, I had the occasion to build and rebuild
> different versions of netcdf.
> 
> I build with --prefix=/usr/local.
> 
> Unbeknownst to me, I ended up with version X of libnetcdf.a and version
> Y (!= X) of netcdf.h installed which caused me no end of grief.

Interesting scenario.  We nomally don't do that without an intervening
"make uninstall" (which, admittedly, is undocumented).

> Today I tracked down the problem to the netcdf install rules.  They read
> something like:
> 
>       $(INCDIR)/$(HEADER):    $(INCDIR) $(HEADER)
>               cp $(HEADER) $@
> 
> This _only_ copies the header file if it is newer than the installed
> version.  But that's not what I want: I want the header and lib
> installed unconditionally when I say "make install".
> 
> The fix is obvious: remove the dependency on $(HEADER) for all install
> rules.  The lib rule is similar, but not normally a problem since the
> lib is rebuilt with each "make" (the header is not!).

A good suggestion. Because some of the installed files are created
dynamically, however, I added "FORCE" to the dependency-list rather than
remove the "$(HEADER)" macros.  As far as this issue is concerned, it's
effectively the same solution because it will cause the rule to be
unconditionally executed.

This change will be in the next release.

> A better fix, to my mind, would be a move towards automake.  
> [I realize that would be a larger time investment on your part,
> so I won't insist :-)]

Yeah, we're short-handed so, as much as we'd like to try that method, we
can't justify it, yet.

Thanks for taking the time to give us some constructive feedback.

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>