Frank, Thanks for sharing your opinion. I do have one question that I hope you will weigh in on. Which of the following two options seems better to you:
1. The GDAL libraries (possibly accompanied with executable programs) are installed as a separately from the GDAL Python bindings. The libraries are installed to \Program Files as you describe and the Python bindings are installed in the standard Python location. A Windows Python programmer wanting to use GDAL would perform two installs: one for the GDAL libraries, the other for the bindings. 2. The GDAL Python bindings include a private copy of the GDAL libraries (with no executable programs). These are installed to a private subdirectory with the bindings. A Windows Python programmer wanting to use GDAL only needs to perform one install: the bindings. #1 is essentially how things are done now, just not following Windows best practices (not using \Program files) and without any automation to ease the process (no regularly maintained installer for the Python bindings). I was proposing #2, basically under the argument that a Windows Python programmer who needs to use GDAL will rarely ever need to use GDAL for some other purpose, and therefore not want to install and think about a separate installation of the GDAL libraries themselves. But if you don't believe that, or think it is important that the libraries remain distinct from the bindings in this scenario for some other reason, then we would appreciate your opinion. Thanks, Jason -----Original Message----- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam Sent: Thursday, January 06, 2011 5:01 PM To: gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0 On 11-01-06 04:42 PM, Christopher Barker wrote: > On 1/6/11 12:31 PM, Jason Roberts wrote: >> Here are some comments on specific parts of your mail: >>> Program Files\GDAL\1.6\gdal.dll >>> and >>> Program Files\GDAL\1.6\gdal.dll > >> Those would be reasonable locations for GDAL to live if the GDAL team >> decided to distribute the GDAL binaries using an installer that adhered to >> the best practices on Windows. > > I *think* we're heading for a consensus to do that, but not many people have > been on this thread. Jason / Christopher, I have no objection to using \Program Files\GDAL\<major>.<minor>\ as a standard location for GDAL stuff on windows. If this is done, the GDAL data search location should be compiled in for this location on windows, much as it defaults to /usr/share/gdal (or /usr/local/share/gdal) on linux. Note that this means point releases cannot coexist on a system. I think that is mostly a good thing, in that upgrading to a new point release should not change the ABI and should be a transparent change for any applications. That is also why we do not encode the point release values in the DLL name. That is the GDAL17.DLL from GDAL 1.7.3 should be a drop in replacement for the GDAL17.DLL from GDAL 1.7.2. If the DLL name was more specific then applications would be forced to relink to use the new version. On the other hand, we do want major relases (1.7.x vs. 1.8.x) to coexist and it is decision that applications need to make which they want to use. So the proposed structure handles that well. I'm going to stay out of the Python specific aspects. Best regards, -- ---------------------------------------+------------------------------------ -- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
