[GRASS5] Re: GRASS <-> GDAL circular references

[Paul Kelly]

On Mon, 24 May 2004, Radim Blazek wrote:

> On Friday 21 May 2004 18:12, Paul Kelly wrote:
>>
>> Yes it will compile OK (though maybe not on all systems, e.g. Cygwin with
>> shared DLLs) but that's not what the problem was: the circular dependencies
>> in Radim's proposal for GDAL using GRASS shared libraies are still there
>> and the dilemma is still valid (and I don't have the answer to that).
>
> But it is true that gproj does not need to be (should not be) linked with
> gdal library?
> In general, should be EXTRA_LIBS removed from libraries' Makefiles?

I used to think that they could but I don't now. Markus originally put 
them in so the compilation with shared libraries on Mac OSX would work. 
And then we found a compiler option (-undefined suppress IIRC) that worked 
around this.

But I have since found that they need to be there when compiling with 
shared libraries on Cygwin (as far as I can remember it was discussed on 
the list that there was no way to allow undefined symbols in Cygwin DLLs).

>
> Could it be gproj staticaly linked with libgdal.a?

I think so yes---it wouldn't make the gproj library any bigger---it only 
seems to check for undefined symbols there at that stage. libgdal.a would 
only be linked into the binary of the module that actually used it. But it
would be linked into every module and if e.g. libgdal.a was linked into every 
vector module it would make things rather big.

Maybe the functions in convert.c could go into a special GRASS/GDAL 
interface library, something like a new version of libgrass. I only 
noticed after I had done most of the work on GPJ_wkt_to_grass() 
etc. that Frank had written some slightly similar projection information 
conversion functions that are in libgrass but not in any version of GRASS 
itself, or GDAL. I suppose the projection information conversion functions 
are really only needed when importing or exporting data, so they should be 
grouped with the other functions that do that.

Paul