Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Ari Jolma]

Tamas,

In Perl the programmer can postpone loading the external DLL required by 
a module. Thus a similar approach is viable in Perl. But that's not how 
it's usually done. If you have a DLL in a system that is meant for 
shared use then it should be in the system PATH. Thus I believe the 
policy should be to set the PATH if GDAL is installed into a system (as 
such - not as a part of something else). Only if a package installs a 
private GDAL, it should be kept out of PATH and the package executables 
need to take care of setting the PATH or other env vars as appropriate 
(in Geoinformatica I do this - the Geoinformatica installer is basically 
a file copy and no env vars are changed).

Ari

6.1.2011 16:50, Tamas Szekeres kirjoitti:
> Ari
>
> The only wokaround which is satisfactory to me is to set the required 
> enviroment at run time before the gdal bindings are used. In csharp we 
> can do something like:
>
>                     string path = 
> Environment.GetEnvironmentVariable("PATH");
>                     if (!path.Contains(gdal_bin_path))
>                     {
>                         Environment.SetEnvironmentVariable("PATH", 
> gdal_bin_path + ";" + path);
>                     }
>                     Gdal.SetConfigOption("GDAL_DRIVER_PATH", 
> gdal_driver_path);
>
> But it requires that loading the gdal dll is happening when the 
> interface is used actually (in Gdal.SetConfigOption with the code 
> above). This is the case with the .NET runtime,  but I'm not sure how 
> do we stand with the other bindings in this regard.
>
> Futher problem with this solution is that this startup code should be 
> placed in the user's script and not sure how this could be implemented 
> in the gdal bindings itself.
>
> Best regards,
>
> Tamas
>
>
>
>
> 2011/1/6 Ari Jolma <ari.jolma at gmail.com <mailto:ari.jolma at gmail.com>>
>
>     On 01/06/2011 03:25 PM, Tamas Szekeres wrote:
>
>
>         Assuming we install the gdal-perl modules in a standard
>         location (not sure where it is), do we have a common mechanism
>         in the perl runtime to find the dependent dlls without having
>         to violate system wide settings (like the PATH environment
>         variable)?
>
>
>     :) I'm not completely satisfied (I'm also not sure I really
>     understand the whole f* issue) with how Perl searches for dll's -
>     especially dll import libs - in Windows.
>
>     But that's configure/compile time issue. In compile time a Perl
>     GDAL dll (for the bindings) is created and put into some location,
>     which is known to Perl and Perl knows how to find it in runtime.
>
>     Assuming I've built the binaries, then in runtime (when the GDAL
>     module is called for) I think somebody (because the Perl GDAL
>     module dll has a link to GDAL dll that was put there in compile
>     time) asks for the GDAL dll's and they simply need to be
>     available. Thus, if there is GDAL in the system (for example in
>     c:\Program Files\Share\GDAL\bin) then that path needs to be in the
>     PATH - I don't think there is a way around that. The PATH may be a
>     temporary PATH set by somebody for Perl programs, but I think the
>     policy should be that when you run GDAL.msi, the system default
>     PATH is modified to have the path to the GDAL binaries.
>
>     Best regards,
>
>     Ari
>
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/010eada6/attachment.html