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

[Jason Roberts]

Frank,

> I would suggest building it as an installer .exe, perhaps using NSIS as
> I did for FWTools, or perhaps the method mentioned by Jurgen produces
> a nice installer.

If possible, I would suggest the final output be a .msi (Windows Installer
package) rather than a .exe. In an effort to make the average user more
secure, Microsoft continues to clamp down on the flexibility afforded to
.exe installers, due to the trouble of disambiguating them from malicious
programs. It was a big shock when Windows Vista was introduced and it
prevented .exe installers from truly running with administrative rights even
if the logged on user was an administrator. Everybody knows about that issue
now and has learned how to modify their .exe to request those rights
(causing the user to be prompted for confirmation) but who knows what
Microsoft will do next. For that reason, I believe it would be better to
bite the bullet and adhere to their recommended installation format.

Microsoft's Visual Studio has long had an easy mechanism for building .msi
installers. It is what I would recommend for this, unless you prefer to use
a FOSS alternative, in which case I cannot advise on what would be good.
There are many. Perhaps Jürgen has a better idea.

> 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?  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.

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. Because the GDAL binaries will
not normally be in the PATH, only when the user is wanting to use the GDAL
utilities, the mere presence of a large number of supporting libraries will
not be an issue. As you noted, it is when it comes to integration that there
is a problem.

I don't think there's an easy answer for the minimalist/maximalist question.
I think it would be best to err on the maximimalist side, with the idea of
providing as fully-functional command line suite as possible. But if there
are particular libraries that are known to cause problems for popular
integration scenarios but are rarely used by command-line users, then leave
them out. I don't know how to identify such libraries; the GDAL team and
power users are the best source of that info. Over time, you can hopefully
ease any problems by moving things to plugins that are only loaded on
demand, allowing someone to integrate without hitting a problem unless the
plugin is loaded.  In the end, integrators are likely to be skilled
programmers and their fallback position will be to build a private copy of
GDAL with the select dependencies they need.

> 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).
>
> Man, I'm really tempted to leap into this myself but I have so many
> other outstanding items right now.  I am willing to assist in an
> effort by a small (2-3 people?) team.

I would be happy offer opinions, review, and test but am not available to
lead at this point. As the developer of the primary source of Windows builds
of GDAL, I think Tamas is the logical leader for this if he is available.

Thank you for seeing this as an important priority.

Jason