From: Arlindo da S. <da...@al...> - 2008-05-15 01:32:49
|
On Wed, May 14, 2008 at 11:47 AM, Jennifer Adams <jm...@co...> wrote: > > > Why should grads.o be different for grads and gradsdap? There are no netcdf > dependent calls in there. All the netcdf library calls are in gasdf.c, > gaio.c and gauser.c -- these three files have: > #include netcdf.h > and have separate .o files when linking grads and gradsdap. The other .o > files that are separated for the two executables are gaddes and gacfg > because there are some netcdf dependencies there but no calls to the > library. > > Sorry, I didn't quite answer your question last time. As you stated, one only needs a single grads.o as there is no netcdf or sdf calls in there. What makes it confusing is that by including gasdf.h (and indirectly) netcdf.h in grads.c you create a misleading dependency between these 2 files (as far as the build system is concerned there is a dependency: you can't compile grads.c without supplying a netcdf.h). Unless someone examines every line of grads.c it appears that grads.c does depend on netcdf.h. So, technically it is not a "bug" as it has no side effects in today's codebase, but it would be much safer to eliminate the inclusion of netcdf.h in grads.c altogether. My overall point is that by slowly adopting encapsulation and other OO constructs (as it can be done in the constraints of good old C) one could make the grads codebase easier to extend and maintain. At this early stage of development, GrADS v2 still shares the same monolithic architecture o v1. Do you you see it this way? Arlindo -- Arlindo da Silva da...@al... |