[Gdal-dev] Proposal for Unified Windows Binaries

[Tamas Szekeres]

>
> 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 support the idea very much, and hopefully it's not impossible
to achieve the desired result. But I would like to see that the core
and the complementary components are fit into same package creation
environment. The developer (componrnt owner) would be responsible to
implement the make process for the variations but the actual building
and packaging would be done on the same common environment (with the
same SDK-s installed etc.).

Moreover it would be desirable establish the technology rules the
various OSGEO projects follow in order to fit into a common
installation system. Are you thinking solely about the GDAL project?
It would be great if we can handle whether a component depends on a
particular version of another component should also be installed. How
can we eliminate the need of the side-by-side execution of the
different versions of the same component in some cases? These are not
issues for the ms4w or FWTools approach, since all of the package was
bound to a specific version of a particular component.

We should at least consider:

1. The component boundaries of the implementation.
2. The expected location of the files in the target environment.
3. How the components relate to each other, dependencies, required versions.
4. Choose a proper installation framework.

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

I agree. And it would also be great to eliminate the common problems
caused by the nature of the Windows environment at the implementation.

Best regards,

Tamas