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

[Christopher Barker]

On 1/6/11 7:55 PM, Frank Warmerdam wrote:

> One question not discussed is whether GDAL should be minimalist or
> maximalist. That is, do we want to include as many formats as possible
> despite the fact that it drags in lots of supporting libraries?

+1 for Maximalist. We want as many things as possible to "just work"

> If we
> just use whatever decision OSGeo4W uses then we will have a fairly
> maximalist solution which is ok I suppose but might make integration of
> the resulting GDAL in other complex applications messy.

People that are integrating into complex apps will likely roll their own 
anyway.

> I would like to suggest production of such an installer be done in such
> a way that the generating scripts live in SVN somewhere, and with
> instructions for the process in the wiki so it isn't all tied to one
> person (as FWTools was).

Absolutely!

On 1/6/11 8:23 PM, Jürgen E. Fischer wrote:
> You get a desktop link
> and a start menu entry that both opens a command line window from where you can
> use GDAL

very nice.

> and start python with gdal available.

what Python gets started? Can you start Python from any other command 
line and have it work, or do you need ENV VARS set up?

On 1/7/11 2:26 AM, Tamas Szekeres wrote:
> However naming the install root folder to GDAL doesn't seem to be a
> right thing as we provide other packages like mapserver as well.

well, either you can have GDAL in GDAL, and mapserver in MapServer. or...

 > I would also mention OSGeo as the root,

If there are a number of things under the OSGeo umbrella provided by the 
same people, then OSGeo is a fine root. Note that I'd have:

Program Files\OSGeo\GDAL
Program Files\OSGeo\Mapserver
....

rather than dumping everything directly in OSGeo\ -- though maybe a 
shared "bin" does make sense? Oh for some standards!

> but I'm not sure how it
> will violate the files if a similar installer will ever derived from an
> OSGeo4W bundle. (We may probably warn the user not to install both
> versions side by side)

Ideally, the OSGEo4W bundle will be compatible -- that really would be 
better --i.e. a GDAL binary is a subset of an OSGeo install. But if 
that's not possible, then we'll just have to use a different name than 
OSGeo4W does.


> IMO, there are two primary goals of this packaging of GDAL: provide easy
> access to just the GDAL command line utilities (separate from larger tool
> suites such as FWTools and OSGeo4W), and provide the GDAL libraries in a
> well-known location so they can be located by the various GDAL bindings. I
> think a secondary goal is to provide GDAL libraries in a well-known location
> for integration by arbitrary applications.

good summary.


 > For example, if you guarantee that all 1.8.x releases
> will have compatible ABIs—that you will never introduce a change that
> will break the binary interface

guarantee is a strong word, but that is the idea as I understand it.

> Therefore the bindings must be changed to look for the GDAL libraries in
> the well-known location.

(or more than one, but I think one is a good start). It seems on *nix, 
for instance, this would generally happen in the build stage (actually 
configure) -- the builder specifies where they want it installed, and 
everything is built to match that. That's a fine model to follow. I 
don't know if there is any equivalent of ./configure for Windows 
building, but a simple script could at least do this bit easily enough.

> The
> user will have to be aware that they must install a compatible pair of
> bindings + GDAL. The GDAL team should decide right now about the X.Y vs.
> X.Y.Z compatibility question.

yes -- and If we go with X.Y, then you should be able to drop an updated 
point release of GDAL in, without updating the bindings. Is that good, 
however, or are the bindings also updated, and tightly related? I think 
you could do X.Y, but have the bindings check for point version 
compatibility, so you'd get a Warning if you were using a mismatched 
binding.

> Let me just recall that OSGeo4W proposes the default install directory
> as C:\OSGeo4W

not a bad option either, but is that difficult/impossible/ugly with 
recent MS security policies (still on XP here...)? Ugly though it is, 
there is a lot to be said for conforming to MS recommended practice.

>> Following up on that point: I think we’ve agreed that we do not want
>> the user
>> to have to set the PATH in order to have the GDAL bindings work.
>
> I do *not* agree that installing GDAL would necessarily insert it into the
> global PATH.

I think we have ways of getting the bindings to work without global PATH.

> It might, or might not, but I'm still very concerned about
> possible interference with other applications using GDAL.

I'd want global PATH settings for command line tool usage. using it for 
finding dlls seems like a really bad idea. With that in mind, perhaps 
the command line tools should be in a different dir from the dlls, so 
that you can put the former on your global PATH without breaking any 
linking.

Whether the executable path is added to the PATH by the installer is 
open for discussion -- I'd appreciate a selectable option to do so, but 
it's not a big deal -- hopefully anyone using command line tools has 
figure out how to set PATH.


> An alternative idea is to store the location of the GDAL libraries in
> the registry and then permitting them to be installed anywhere with no
> consequences.

I think this is an uglier piece of Windows-ism that spaces in file 
names, but that's just MHO...


> Just by thinking about the details if we implement a smart dll loader
> which could in fact work with any locations to load the dll-s why do we
> require to use a specific folder as the install location?

Standardized defaults are still a good idea -- makes it much easier to 
debug newbie install problems...

> The installer may create a registry entry or a config

Where would that go? And you already know what i think of the registry 
solution. This also puts a bunch more platform specific code in the 
bindings, not a huge deal, but a deal non the less.

>  I'm tending to think that this part should probably be
> implemented in a generic way (which doesn't change frequently) and be
> installed in a common folder available in the PATH.

Now we're back to common, standard locations again -- why not just put 
GDAL there?


> I will start an RFC for this next week.


Thanks for all your work on this!

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov