[Gdal-dev] Proposal for Unified Windows Binaries

[Howard Butler]

On Apr 15, 2007, at 5:48 PM, Tamas Szekeres wrote:

> Howard,
>
> I'm not sure I could follow all of the aspects of this proposal, It's
> worth considering to create an RFC describing the related changes in
> the makefiles for the better understanding.

I agree that this is RFC worthy, but I just wanted to float the idea  
and see if there is general support for it.  I volunteer to write the  
RFC when it appears we have some consensus on an approach we are  
going to take.  I would most like to hear from other developers using  
GDAL/OGR on windows and how our production of binaries can make their  
lives easier.

>
> I agree with the aim of splitting up a binary package to various
> sub-components  can be installed separately and creating a common core
> component hosting the GDAL/OGR core implementation. The GDAL C API can
> possibly be the primary separation boundary for this isolation.

The C API is certainly the boundary as far as the language bindings  
are concerned...

>
> But I would completely disagree if we would want to take out the
> binaries of the scripting interfaces and let the user to create this
> code by hand or obtain the corresponding bundle from a different
> location. Instead, I would extend the pactice for adding these
> binaries for all of the bindings in a more unique way. For example
> adding some common makefile targets to create the code for this
> purpose, and allow the interface maintainers to decide which files
> should be included in the package and to which location.

I am proposing that they obtain the bundle separately from the "GDAL  
base" distribution.  They might get it from the same place, but I  
think it should be separate.  There's just too many variations  
otherwise.  For example, I want Python 2.3, Java 1.4, and .NET 1.1  
bindings all at once... or, I want Python 2.5 next-gen, .NET 2.0, and  
Java 1.5.  If we're to just pick a set and distribute them  
altogether, it's invariably wrong for somebody.  Instead, I would  
propose that we build a Python 2.4 and 2.5 (or .NET 1.1 and 2.0) set  
of bindings and provide them for download separately (or even package  
them separately in a all-in-one-style installer kind of like FWTools  
does plugins currently).  Then the user (which I assert is more  
frequently a developer who's stuffing GDAL in something else) can mix  
and match the pieces they need.  I'm not recommending that users have  
to compile language bindings themselves, but rather recommending that  
they obtain them separately from the GDAL base distribution.   
Additionally, I'm recommending that the language bindings (in binary  
form) be tailored in such a way as to make them as simple as possible  
to bolt on to the GDAL base distribution.

>
> I would also keep on providing the related dll-s (like proj.dll) in
> the package to support a ready to use installation.

Proj, OGR, and GML fall into my "required" list, but I think we  
should argue the finer points of what to include and what not to  
include after we reach some consensus on the general idea of a GDAL  
base distribution.  I will state that this approach will be really  
nice for the exotics (SDE, Oracle, etc), which have *their own*  
quadratic variations of version pain going on.

>
> I also have some doubts how to create an unique compilation that is
> suitable for all of the applications and the various needs.

I don't think GDAL base solves everyone's needs, but I'm hoping it  
can cover more needs than we are currently covering with FWTools and  
MS4W (with respect to GDAL only...each binary has much different  
supporting members).  I also think it is important to focus a bit  
more on other developers embedding and linking GDAL in their  
applications.  I think our current Windows binary offerings cater  
mostly to end-user types rather than developer types, and I think the  
developer types spread GDAL further and wider in a shorter amount of  
time.

Howard