It looks like several people have started an autoconf build for NCO, but I guess nothing has ever become stable. Like others, I'd like to learn how to use autotools by trying it out on NCO. I couldn't find the previous work, so I started from scratch (which is probably not bad for the learning process).
Anyway, I've gotten started, but I have several questions about the current build. I've got it working on my Debian gnu/linux system and a Solaris8. I don't have access to several other architectures, so it may prove difficult for me to incorporate them. Anyway, here are some points, followed by some questions.
1)I had to change ncap.l to ncap_lex.l and ncap.y to ncap_yacc.y because automake wants to name lex/yacc stuff to the basename with .c. (i.e. it moves lex.yy.c to ncap.c, and then y.tab.c to ncap.c) Without renaming, the first file gets overwritten by the second before linking, and the original ncap.c would override them all.
2)I'm putting the preprocessor symbols in config.h, so ncap.c needs to #include it for the determining whether to #include getopt.h
3) I made OPTS=X into --enable-debugging, OPTS=X into --enable-warnings (there is probably something better). The case structures in configure.in need to be filled out for architectures I don't have, but the prototypes are in there (empty for now.)
4) I added --with-fortran to set the USE_FORTRAN_ARITHMATIC flag. There is some checking of these options for correct settings, (i.e. 'yes' or 'no'), otherwise the default is used.
5) I added --with-dods to use it. However, I haven't added DODS to my computer yet, so I'm not sure if it works properly. However, the library is getting linked, and it uses the environment variable $DODS_ROOT if it is set, defaulting to /usr/local/DODS otherwise.
6) there is a final case structure in configure.in to set variables like SUN4SOL2, AIX, SUNMP, etc. based on the OS, CPU and VENDOR that autoconf finds. Some tweaking is necessary here since the two sets won't like up perfectly. However, it doesn't look like all the possible options in pvmgetarch are used anywhere in NCO's exisiting programs, so they can just be added as they are needed. Again, an empty case structure is there, ready to be added to.
7) I used libtool, so shared objects are build when they can be (or at least should be).
8) the documentation dir and c++ dir's have not been added yet.
9) there are lots of libraries that are conditionally linked with in the current Makefile. I haven't added them properly to configure.in yet because I haven't found where they are used. They are in there, just commented out right now.
QUESTIONS:
1) I don't see where the fortran files are being compiled under any architecture. Thus, I haven't added any fortran autconf stuff yet. How, when and where are they compiled? The current Makefile has FFLAGS and FC defined, but I don't see them being used in the current build (at least on my systems.)
2) autoconf automatically uses the debugging symbol -g. You may be able to override that, but I'm not sure where yet. Is there a reason not to add it always (when possible)? Are we concerned with speed? I see OPTS=D sets DEBUG, but i don't see it used in any NCO files.
I have my working copy of the this build gzip'ed at
puff.images.alaska.edu/temp/
if you want to see it for some reason. configure.in has some comments, the other files are either generated or the default. Thanks for the help.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will try to respond to this more fully later.
I'm not sure what libraries you're referring to
in your point 9. The rest of your points
sound like you made reasonable decisions.
Here are quick answers to questions 1--3:
1. Fortran routines were deprecated in nco-2.2.0
and completely removed in nco-2.3 or 2.4 I believe.
So there's no immediate need for there support unless
you want to resurrrect them and maintain them too.
2. Yes we are very concerned with speed, although -g may not reduce speed at all (I know little about this kind of thing). size of executable is another disadvantage of -g. this could be fixed by adding
a strip option (already in Makefile I believe).
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
contains the autoconf work done by the last person to attempt
this project. it's an earlier version of NCO, but I thought you
might benefit from looking at what he did and reading the
discussions we had.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 1)I had to change ncap.l to ncap_lex.l and ncap.y to ncap_yacc.y because automake wants to name lex/yacc stuff to the basename with .c. (i.e. it moves lex.yy.c to ncap.c, and then y.tab.c to ncap.c) Without renaming, the first file gets overwritten by the second before linking, and the original ncap.c would override them all.
OK, changing names is no big deal.
> 2)I'm putting the preprocessor symbols in config.h, so ncap.c needs to #include it for the determining whether to #include getopt.h
yes, I assume all files with machine/OS dependencies will need config.h
> 3) I made OPTS=X into --enable-debugging, OPTS=X into --enable-warnings (there is probably something better). The case structures in configure.in need to be filled out for architectures I don't have, but the prototypes are in there (empty for now.)
Here's the legend to the current Makefile:
OPTS=O Optimize
OPTS=R Regular
OPTS=D Debugging (your basic -g)
OPTS=X Extreme debugging (i.e., bounds checking, pedantic, and the whole works)
> 4) I added --with-fortran to set the USE_FORTRAN_ARITHMATIC flag. There is some checking of these options for correct settings, (i.e. 'yes' or 'no'), otherwise the default is used.
we've already covered this
> 5) I added --with-dods to use it. However, I haven't added DODS to my computer yet, so I'm not sure if it works properly. However, the library is getting linked, and it uses the environment variable $DODS_ROOT if it is set, defaulting to /usr/local/DODS otherwise.
yes, please try to get this working and have DODS automatically
enabled if the library can be found by autotools, with a --no-dods
switch to turn it off if requested.
> 6) there is a final case structure in configure.in to set variables like SUN4SOL2, AIX, SUNMP, etc. based on the OS, CPU and VENDOR that autoconf finds. Some tweaking is necessary here since the two sets won't like up perfectly. However, it doesn't look like all the possible options in pvmgetarch are used anywhere in NCO's exisiting programs, so they can just be added as they are needed. Again, an empty case structure is there, ready to be added to.
That's true. The pvm_arch stuff should eventually become obsoleted by
the autotools macros and build tests. e.g., right now ncap.c has a lot
of functions like, e.g., acosh() that it does not implement because
it can't find the corresponding float function acoshf(). I expect that
autoconf can automate a lot of this with macros so that ncap.c can
be rewritten to use
> 7) I used libtool, so shared objects are build when they can be (or at least should be).
great. this would be a big win for NCO.
> 8) the documentation dir and c++ dir's have not been added yet.
note also the relatively new man dir.
> 9) there are lots of libraries that are conditionally linked with in the current Makefile. I haven't added them properly to configure.in yet because I haven't found where they are used. They are in there, just commented out right now.
do you mean i18n and hdf stuff?
> QUESTIONS:
> 2) autoconf automatically uses the debugging symbol -g. You may be able to override that, but I'm not sure where yet.
this is probably overridable
> Is there a reason not to add it always (when possible)? Are we concerned with speed? I see OPTS=D sets DEBUG, but i don't see it used in any NCO files.
DBG is not used for anything yet
> I have my working copy of the this build gzip'ed at
> puff.images.alaska.edu/temp/
> if you want to see it for some reason. configure.in has some comments, the other files are either generated or the default. Thanks for the help.
>
> rorik
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
# these have yet to be added. Are they all really used, and if so, where?
The are all machine/OS/compile-time dependent
# FIXME: Replace `main' with a function in `-lC':
#AC_CHECK_LIB([C], [main])
used on AIX to provide cosf()...
# FIXME: Replace `main' with a function in `-lF77':
#AC_CHECK_LIB([F77], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lM77':
#AC_CHECK_LIB([M77], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lVaxlib':
#AC_CHECK_LIB([Vaxlib], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lccmalloc':
#AC_CHECK_LIB([ccmalloc], [main])
linux library to check for memory leaks when OPTS=X
# FIXME: Replace `main' with a function in `-ldf':
#AC_CHECK_LIB([df], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-ldl':
#AC_CHECK_LIB([dl], [main])
linux library to check for memory leaks when OPTS=X
# FIXME: Replace `main' with a function in `-lf':
#AC_CHECK_LIB([f], [main])
# FIXME: Replace `main' with a function in `-lftn':
#AC_CHECK_LIB([ftn], [main])
# FIXME: Replace `main' with a function in `-ljpeg':
#AC_CHECK_LIB([jpeg], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-ll':
#AC_CHECK_LIB([l], [main])
Lex library (not required with flex, just with lex, I believe)
# FIXME: Replace `main' with a function in `-lmfhdf':
#AC_CHECK_LIB([mfhdf], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-lnco':
#AC_CHECK_LIB([nco], [main])
homegrown NCO library
# FIXME: Replace `main' with a function in `-lrx':
#AC_CHECK_LIB([rx], [main])
Use only when --enable-DODS defined
# FIXME: Replace `main' with a function in `-lsocket':
#AC_CHECK_LIB([socket], [main])
Solaris only I believe
# FIXME: Replace `main' with a function in `-lthread':
#AC_CHECK_LIB([thread], [main])
Solaris only I believe
# FIXME: Replace `main' with a function in `-lwww':
#AC_CHECK_LIB([www], [main])
Use only when --enable-DODS defined
# FIXME: Replace `main' with a function in `-lxlf':
#AC_CHECK_LIB([xlf], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lxlf90':
#AC_CHECK_LIB([xlf90], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-ly':
#AC_CHECK_LIB([y], [main])
Yacc library
# FIXME: Replace `main' with a function in `-lz':
#AC_CHECK_LIB([z], [main])
Use only when --enable-HDF5 defined
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
back from the long weekend. I've hacked configure.in a little more, now --with-dods defaults to yes. Unless you specify --without-dods (or --with-dods=no), configure looks for the libraries necessary. If $DODS_ROOT is defined, it adds that to the $LDFLAGS before looking. If any of the libraries fail to be found and linked, it emits a warning; otherwise the variable $DODS=1 is defined.
I did the same with --with-hdf5, except $HDF5=1 is defined instead if everything succeeds. I'm wondering if all the libraries you listed above are required for HDF5 support (ie mfhdf jpeg df z hdf5 f ftn). The only HDF5 calls I found are in nco_netcdf.c, and the functions are H5Fcreate, H5Fopen, H5Fclose, which are in libhdf5. Thus, it seems like checking for, and linking to, libhdf5 should be sufficient.
I've changed the options to --enable-debug, --enable-exteme, and --enable-optimize. It seems like the compile and link options should be based on the compiler and linker, and not the OS. My original configure.in had a case structure based on $host_os, but I think it should be based on $CC. For example
if test "enable-extreme" = "yes"; then
case $CC in
gcc) CFLAGS="$CFLAGS -g -Wall -inline-debug-info";;
cc) CFLAGS="$CFLAGS -N 132";;
xlc) CFLAGS="$CFLAGS -qflttrap -qidirfirst";;
esac
fi
However, the current Makefile sets the compiler ($CC) based on the OS, and then sets extra linker and compiler flags. So there is not a direct correlation between the two; sometimes the same compiler ends up with different flags on different OS's. I don't have access to all these different compilers, but maybe we could set up a table of the various options that go with the respective compilers.
compiler optimize debug extreme
--------------------------------
gcc -O2 -g -g -Wall
cc -O -g -g -N 132
etc...
However, an additional OS-based case structure could be set up within a specific case of $CC if that is necessary.
A lot of the library checks still look for main since I have not found what functions in the libraries are needed, so I can check for those.
> back from the long weekend. I've hacked configure.in a little more,
> now --with-dods defaults to yes. Unless you specify --without-dods (or
> --with-dods=no), configure looks for the libraries necessary. If
> $DODS_ROOT is defined, it adds that to the $LDFLAGS before looking. If
> any of the libraries fail to be found and linked, it emits a warning;
> otherwise the variable $DODS=1 is defined.
Great, this is more like the functionality the existing Makefile has.
Everything may be specified from the command line at compile time.
Not to be too picky, but let's standardize switches a bit, so those
that enable features are all activated with
--enable-foo
and, if enabled by default, may be disabled by
--enable-foo=no or by --disable-foo
> I did the same with --with-hdf5, except $HDF5=1 is defined instead if
> everything succeeds. I'm wondering if all the libraries you listed
> above are required for HDF5 support (ie mfhdf jpeg df z hdf5 f
> ftn). The only HDF5 calls I found are in nco_netcdf.c, and the
> functions are H5Fcreate, H5Fopen, H5Fclose, which are in
> libhdf5. Thus, it seems like checking for, and linking to, libhdf5
> should be sufficient.
This is a little subtle but fortunately the complex stuff is obsolete.
Up to nco-2.2.0, enabling HDF meant linking to the HDF versions of
the netCDF libraries instead of the netCDF versions. That's what
is in mfhdf. jpeg, df, z are additional libraries needed to resolve
mfhdf and hdf libraries. All of that is obsolete because mfhdf does
not support netCDF v. 3.x, which is what nco now uses.
f and ftn are fortran libraries and would only be used with
--enable-fortran-arithmetic
which, as I've said, is also obsolete (although most of the calls
are still there in nco_fortran.F if you want to enable them. I gave
up on it because c-fortran linking is a PITA without autoconf.)
Currently, enabling hdf only requires hdf5, and there is just one
place in the code where I am experimenting with writing native HDF
output. So
--enable-hdf
should be allowed but it's for development only.
> I've changed the options to --enable-debug, --enable-exteme, and
> --enable-optimize.
Good.
> It seems like the compile and link options should
> be based on the compiler and linker, and not the OS.
General agreement here. Existing method is purely for my convenience.
> My original
> configure.in had a case structure based on $host_os, but I think it
> should be based on $CC. For example
> if test "enable-extreme" = "yes"; then
> case $CC in
> gcc) CFLAGS="$CFLAGS -g -Wall -inline-debug-info";;
> cc) CFLAGS="$CFLAGS -N 132";;
> xlc) CFLAGS="$CFLAGS -qflttrap -qidirfirst";;
> esac
> fi
Please generate these cases so as not to lose existing information
from the Makefile if at all possible. Some architectures have both
32 and 64 bit ABIs and you need to choose between the two.
SGI is currently set to default to 64 bit ABI, but AIX defaults
to 32 bit and checks for ABI=64 to see whether to switch.
Does autoconf/libtool have an automated way of doing this?
That would be very helpful. 64 bit ABI can manipulate netcdf files
> 2 GB in size, but 32 bit cannot. There are reasons for using both,
but they must be linked to libnetcdf.a built with same ABI!
If no automated method exists, then we'll need a
--enable-ABI64
option.
> However, the current Makefile sets the compiler ($CC) based on the OS,
> and then sets extra linker and compiler flags. So there is not a
> direct correlation between the two; sometimes the same compiler ends
> up with different flags on different OS's. I don't have access to all
> these different compilers, but maybe we could set up a table of the
> various options that go with the respective compilers.
> compiler optimize debug extreme
> --------------------------------
> gcc -O2 -g -g -Wall
> cc -O -g -g -N 132
Yes, you can generate this table just by duping Make with
how you set PVM_ARCH and then calling with OPTS=O,R,D,X
> However, an additional OS-based case structure could be set up
> within a specific case of $CC if that is necessary.
Yes, Alpha (Tru64) and SGI IRIX both use cc for C compiler (as do
others probably) but switches are different so this is not
hypothetical situation and needs to be architected in from the
beginning.
> A lot of the library checks still look for main since I have not
> found what functions in the libraries are needed, so I can check for
> those.
Send me a list of specific libraries you need member routines for.
It looks like several people have started an autoconf build for NCO, but I guess nothing has ever become stable. Like others, I'd like to learn how to use autotools by trying it out on NCO. I couldn't find the previous work, so I started from scratch (which is probably not bad for the learning process).
Anyway, I've gotten started, but I have several questions about the current build. I've got it working on my Debian gnu/linux system and a Solaris8. I don't have access to several other architectures, so it may prove difficult for me to incorporate them. Anyway, here are some points, followed by some questions.
1)I had to change ncap.l to ncap_lex.l and ncap.y to ncap_yacc.y because automake wants to name lex/yacc stuff to the basename with .c. (i.e. it moves lex.yy.c to ncap.c, and then y.tab.c to ncap.c) Without renaming, the first file gets overwritten by the second before linking, and the original ncap.c would override them all.
2)I'm putting the preprocessor symbols in config.h, so ncap.c needs to #include it for the determining whether to #include getopt.h
3) I made OPTS=X into --enable-debugging, OPTS=X into --enable-warnings (there is probably something better). The case structures in configure.in need to be filled out for architectures I don't have, but the prototypes are in there (empty for now.)
4) I added --with-fortran to set the USE_FORTRAN_ARITHMATIC flag. There is some checking of these options for correct settings, (i.e. 'yes' or 'no'), otherwise the default is used.
5) I added --with-dods to use it. However, I haven't added DODS to my computer yet, so I'm not sure if it works properly. However, the library is getting linked, and it uses the environment variable $DODS_ROOT if it is set, defaulting to /usr/local/DODS otherwise.
6) there is a final case structure in configure.in to set variables like SUN4SOL2, AIX, SUNMP, etc. based on the OS, CPU and VENDOR that autoconf finds. Some tweaking is necessary here since the two sets won't like up perfectly. However, it doesn't look like all the possible options in pvmgetarch are used anywhere in NCO's exisiting programs, so they can just be added as they are needed. Again, an empty case structure is there, ready to be added to.
7) I used libtool, so shared objects are build when they can be (or at least should be).
8) the documentation dir and c++ dir's have not been added yet.
9) there are lots of libraries that are conditionally linked with in the current Makefile. I haven't added them properly to configure.in yet because I haven't found where they are used. They are in there, just commented out right now.
QUESTIONS:
1) I don't see where the fortran files are being compiled under any architecture. Thus, I haven't added any fortran autconf stuff yet. How, when and where are they compiled? The current Makefile has FFLAGS and FC defined, but I don't see them being used in the current build (at least on my systems.)
2) autoconf automatically uses the debugging symbol -g. You may be able to override that, but I'm not sure where yet. Is there a reason not to add it always (when possible)? Are we concerned with speed? I see OPTS=D sets DEBUG, but i don't see it used in any NCO files.
I have my working copy of the this build gzip'ed at
puff.images.alaska.edu/temp/
if you want to see it for some reason. configure.in has some comments, the other files are either generated or the default. Thanks for the help.
rorik
Hi and welcome to NCO,
I will try to respond to this more fully later.
I'm not sure what libraries you're referring to
in your point 9. The rest of your points
sound like you made reasonable decisions.
Here are quick answers to questions 1--3:
1. Fortran routines were deprecated in nco-2.2.0
and completely removed in nco-2.3 or 2.4 I believe.
So there's no immediate need for there support unless
you want to resurrrect them and maintain them too.
2. Yes we are very concerned with speed, although -g may not reduce speed at all (I know little about this kind of thing). size of executable is another disadvantage of -g. this could be fixed by adding
a strip option (already in Makefile I believe).
Charlie
the file
ftp://dust.ps.uci.edu/pub/zender/nco/nco-autoconf1.tar.gz
contains the autoconf work done by the last person to attempt
this project. it's an earlier version of NCO, but I thought you
might benefit from looking at what he did and reading the
discussions we had.
Charlie
> 1)I had to change ncap.l to ncap_lex.l and ncap.y to ncap_yacc.y because automake wants to name lex/yacc stuff to the basename with .c. (i.e. it moves lex.yy.c to ncap.c, and then y.tab.c to ncap.c) Without renaming, the first file gets overwritten by the second before linking, and the original ncap.c would override them all.
OK, changing names is no big deal.
> 2)I'm putting the preprocessor symbols in config.h, so ncap.c needs to #include it for the determining whether to #include getopt.h
yes, I assume all files with machine/OS dependencies will need config.h
> 3) I made OPTS=X into --enable-debugging, OPTS=X into --enable-warnings (there is probably something better). The case structures in configure.in need to be filled out for architectures I don't have, but the prototypes are in there (empty for now.)
Here's the legend to the current Makefile:
OPTS=O Optimize
OPTS=R Regular
OPTS=D Debugging (your basic -g)
OPTS=X Extreme debugging (i.e., bounds checking, pedantic, and the whole works)
> 4) I added --with-fortran to set the USE_FORTRAN_ARITHMATIC flag. There is some checking of these options for correct settings, (i.e. 'yes' or 'no'), otherwise the default is used.
we've already covered this
> 5) I added --with-dods to use it. However, I haven't added DODS to my computer yet, so I'm not sure if it works properly. However, the library is getting linked, and it uses the environment variable $DODS_ROOT if it is set, defaulting to /usr/local/DODS otherwise.
yes, please try to get this working and have DODS automatically
enabled if the library can be found by autotools, with a --no-dods
switch to turn it off if requested.
> 6) there is a final case structure in configure.in to set variables like SUN4SOL2, AIX, SUNMP, etc. based on the OS, CPU and VENDOR that autoconf finds. Some tweaking is necessary here since the two sets won't like up perfectly. However, it doesn't look like all the possible options in pvmgetarch are used anywhere in NCO's exisiting programs, so they can just be added as they are needed. Again, an empty case structure is there, ready to be added to.
That's true. The pvm_arch stuff should eventually become obsoleted by
the autotools macros and build tests. e.g., right now ncap.c has a lot
of functions like, e.g., acosh() that it does not implement because
it can't find the corresponding float function acoshf(). I expect that
autoconf can automate a lot of this with macros so that ncap.c can
be rewritten to use
#ifdef HAVE_CONFIG_H
#include config.h
#endif
...
#ifdef HAVE_ACOSHF
...
#endif
> 7) I used libtool, so shared objects are build when they can be (or at least should be).
great. this would be a big win for NCO.
> 8) the documentation dir and c++ dir's have not been added yet.
note also the relatively new man dir.
> 9) there are lots of libraries that are conditionally linked with in the current Makefile. I haven't added them properly to configure.in yet because I haven't found where they are used. They are in there, just commented out right now.
do you mean i18n and hdf stuff?
> QUESTIONS:
> 2) autoconf automatically uses the debugging symbol -g. You may be able to override that, but I'm not sure where yet.
this is probably overridable
> Is there a reason not to add it always (when possible)? Are we concerned with speed? I see OPTS=D sets DEBUG, but i don't see it used in any NCO files.
DBG is not used for anything yet
> I have my working copy of the this build gzip'ed at
> puff.images.alaska.edu/temp/
> if you want to see it for some reason. configure.in has some comments, the other files are either generated or the default. Thanks for the help.
>
> rorik
Thank you.
# these have yet to be added. Are they all really used, and if so, where?
The are all machine/OS/compile-time dependent
# FIXME: Replace `main' with a function in `-lC':
#AC_CHECK_LIB([C], [main])
used on AIX to provide cosf()...
# FIXME: Replace `main' with a function in `-lF77':
#AC_CHECK_LIB([F77], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lM77':
#AC_CHECK_LIB([M77], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lVaxlib':
#AC_CHECK_LIB([Vaxlib], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lccmalloc':
#AC_CHECK_LIB([ccmalloc], [main])
linux library to check for memory leaks when OPTS=X
# FIXME: Replace `main' with a function in `-ldf':
#AC_CHECK_LIB([df], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-ldl':
#AC_CHECK_LIB([dl], [main])
linux library to check for memory leaks when OPTS=X
# FIXME: Replace `main' with a function in `-lf':
#AC_CHECK_LIB([f], [main])
# FIXME: Replace `main' with a function in `-lftn':
#AC_CHECK_LIB([ftn], [main])
# FIXME: Replace `main' with a function in `-ljpeg':
#AC_CHECK_LIB([jpeg], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-ll':
#AC_CHECK_LIB([l], [main])
Lex library (not required with flex, just with lex, I believe)
# FIXME: Replace `main' with a function in `-lmfhdf':
#AC_CHECK_LIB([mfhdf], [main])
Use only when --enable-HDF5 defined
# FIXME: Replace `main' with a function in `-lnco':
#AC_CHECK_LIB([nco], [main])
homegrown NCO library
# FIXME: Replace `main' with a function in `-lrx':
#AC_CHECK_LIB([rx], [main])
Use only when --enable-DODS defined
# FIXME: Replace `main' with a function in `-lsocket':
#AC_CHECK_LIB([socket], [main])
Solaris only I believe
# FIXME: Replace `main' with a function in `-lthread':
#AC_CHECK_LIB([thread], [main])
Solaris only I believe
# FIXME: Replace `main' with a function in `-lwww':
#AC_CHECK_LIB([www], [main])
Use only when --enable-DODS defined
# FIXME: Replace `main' with a function in `-lxlf':
#AC_CHECK_LIB([xlf], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-lxlf90':
#AC_CHECK_LIB([xlf90], [main])
obsolete used only when linked to fortran
# FIXME: Replace `main' with a function in `-ly':
#AC_CHECK_LIB([y], [main])
Yacc library
# FIXME: Replace `main' with a function in `-lz':
#AC_CHECK_LIB([z], [main])
Use only when --enable-HDF5 defined
back from the long weekend. I've hacked configure.in a little more, now --with-dods defaults to yes. Unless you specify --without-dods (or --with-dods=no), configure looks for the libraries necessary. If $DODS_ROOT is defined, it adds that to the $LDFLAGS before looking. If any of the libraries fail to be found and linked, it emits a warning; otherwise the variable $DODS=1 is defined.
I did the same with --with-hdf5, except $HDF5=1 is defined instead if everything succeeds. I'm wondering if all the libraries you listed above are required for HDF5 support (ie mfhdf jpeg df z hdf5 f ftn). The only HDF5 calls I found are in nco_netcdf.c, and the functions are H5Fcreate, H5Fopen, H5Fclose, which are in libhdf5. Thus, it seems like checking for, and linking to, libhdf5 should be sufficient.
I've changed the options to --enable-debug, --enable-exteme, and --enable-optimize. It seems like the compile and link options should be based on the compiler and linker, and not the OS. My original configure.in had a case structure based on $host_os, but I think it should be based on $CC. For example
if test "enable-extreme" = "yes"; then
case $CC in
gcc) CFLAGS="$CFLAGS -g -Wall -inline-debug-info";;
cc) CFLAGS="$CFLAGS -N 132";;
xlc) CFLAGS="$CFLAGS -qflttrap -qidirfirst";;
esac
fi
However, the current Makefile sets the compiler ($CC) based on the OS, and then sets extra linker and compiler flags. So there is not a direct correlation between the two; sometimes the same compiler ends up with different flags on different OS's. I don't have access to all these different compilers, but maybe we could set up a table of the various options that go with the respective compilers.
compiler optimize debug extreme
--------------------------------
gcc -O2 -g -g -Wall
cc -O -g -g -N 132
etc...
However, an additional OS-based case structure could be set up within a specific case of $CC if that is necessary.
A lot of the library checks still look for main since I have not found what functions in the libraries are needed, so I can check for those.
current effort at
http://puff.images.alaska.edu/temp/
rorik
> back from the long weekend. I've hacked configure.in a little more,
> now --with-dods defaults to yes. Unless you specify --without-dods (or
> --with-dods=no), configure looks for the libraries necessary. If
> $DODS_ROOT is defined, it adds that to the $LDFLAGS before looking. If
> any of the libraries fail to be found and linked, it emits a warning;
> otherwise the variable $DODS=1 is defined.
Great, this is more like the functionality the existing Makefile has.
Everything may be specified from the command line at compile time.
Not to be too picky, but let's standardize switches a bit, so those
that enable features are all activated with
--enable-foo
and, if enabled by default, may be disabled by
--enable-foo=no or by --disable-foo
> I did the same with --with-hdf5, except $HDF5=1 is defined instead if
> everything succeeds. I'm wondering if all the libraries you listed
> above are required for HDF5 support (ie mfhdf jpeg df z hdf5 f
> ftn). The only HDF5 calls I found are in nco_netcdf.c, and the
> functions are H5Fcreate, H5Fopen, H5Fclose, which are in
> libhdf5. Thus, it seems like checking for, and linking to, libhdf5
> should be sufficient.
This is a little subtle but fortunately the complex stuff is obsolete.
Up to nco-2.2.0, enabling HDF meant linking to the HDF versions of
the netCDF libraries instead of the netCDF versions. That's what
is in mfhdf. jpeg, df, z are additional libraries needed to resolve
mfhdf and hdf libraries. All of that is obsolete because mfhdf does
not support netCDF v. 3.x, which is what nco now uses.
f and ftn are fortran libraries and would only be used with
--enable-fortran-arithmetic
which, as I've said, is also obsolete (although most of the calls
are still there in nco_fortran.F if you want to enable them. I gave
up on it because c-fortran linking is a PITA without autoconf.)
Currently, enabling hdf only requires hdf5, and there is just one
place in the code where I am experimenting with writing native HDF
output. So
--enable-hdf
should be allowed but it's for development only.
> I've changed the options to --enable-debug, --enable-exteme, and
> --enable-optimize.
Good.
> It seems like the compile and link options should
> be based on the compiler and linker, and not the OS.
General agreement here. Existing method is purely for my convenience.
> My original
> configure.in had a case structure based on $host_os, but I think it
> should be based on $CC. For example
> if test "enable-extreme" = "yes"; then
> case $CC in
> gcc) CFLAGS="$CFLAGS -g -Wall -inline-debug-info";;
> cc) CFLAGS="$CFLAGS -N 132";;
> xlc) CFLAGS="$CFLAGS -qflttrap -qidirfirst";;
> esac
> fi
Please generate these cases so as not to lose existing information
from the Makefile if at all possible. Some architectures have both
32 and 64 bit ABIs and you need to choose between the two.
SGI is currently set to default to 64 bit ABI, but AIX defaults
to 32 bit and checks for ABI=64 to see whether to switch.
Does autoconf/libtool have an automated way of doing this?
That would be very helpful. 64 bit ABI can manipulate netcdf files
> 2 GB in size, but 32 bit cannot. There are reasons for using both,
but they must be linked to libnetcdf.a built with same ABI!
If no automated method exists, then we'll need a
--enable-ABI64
option.
> However, the current Makefile sets the compiler ($CC) based on the OS,
> and then sets extra linker and compiler flags. So there is not a
> direct correlation between the two; sometimes the same compiler ends
> up with different flags on different OS's. I don't have access to all
> these different compilers, but maybe we could set up a table of the
> various options that go with the respective compilers.
> compiler optimize debug extreme
> --------------------------------
> gcc -O2 -g -g -Wall
> cc -O -g -g -N 132
Yes, you can generate this table just by duping Make with
how you set PVM_ARCH and then calling with OPTS=O,R,D,X
> However, an additional OS-based case structure could be set up
> within a specific case of $CC if that is necessary.
Yes, Alpha (Tru64) and SGI IRIX both use cc for C compiler (as do
others probably) but switches are different so this is not
hypothetical situation and needs to be architected in from the
beginning.
> A lot of the library checks still look for main since I have not
> found what functions in the libraries are needed, so I can check for
> those.
Send me a list of specific libraries you need member routines for.
> current effort at
> http://puff.images.alaska.edu/temp/
Thanks,
Charlie
> rorik