Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
On 04/09/2010 02:09 AM, Thomas Orgis wrote:
Am Thu, 08 Apr 2010 13:19:46 -0600 schrieb Ed Hartnett<ed@xxxxxxxxxxxxxxxx>:* A new nc-config script to help users build netCDF programs without having to deduce all the needed compiler options.I have an issue with nc-config ... it contains too many flags. Example: I build NetCDF with FFLAGS="-O -g -M/prefix/include" (since I have figured out to need the -M for using Fortran with this compiler) ... then, the resulting nc-config will return this: shell$ nc-config --fflags -O -g -M/prefix/include -M/prefix/include So it packs my FFLAGS in front and adds the -M path for the module. What I expect from such a tool is that it _only_ adds the -M part (or -I for GNU compiler). Not only is it redundant to have my optimizations specified twice when including $(nc-config --fflags) into my FFLAGS, it can actually cause conflicts with other (optimization) flags I choose. Is there a special reason why all of FFLAGS from the build is included in nc-config? I am aware of at least one compiler (I think it was open64) that, given some advanced optimization flags, produces libraries that are incompatible with programs built with more conservative flags. But that is a rare case and should rather be considered a bug in the compiler... or a special option for crazy people that should at least make sure they build everything with one set of flags. Alrighty then, Thomas.
I agree that they should not be present, as with cflags: cflags=" -I${includedir}" fflags="@FFLAGS@ @MOD_FLAG@${includedir}" -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxxxxxxx Boulder, CO 80301 http://www.cora.nwra.com
netcdfgroup
archives: