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.bar...@noaa.gov
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
