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

[Jason Roberts]

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-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Thursday, January 06, 2011 5:01 PM
To: gdal-dev at 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,
warmerdam at 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 at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev