[Gdal-dev] Proposal for Unified Windows Binaries

[Frank Warmerdam]

Tamas Szekeres wrote:
> 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.

Tamas,

I don't think Howard was proposing any changes to the makefiles.
But rather that the "core component" we would build on would be
the GDAL/OGR C++ core, the C API, plus all the drivers that have
odd requirements built as plugins so they are optional.  Stuff that
depends on external DLLs, has runtime requirements, etc.

Then stuff like the C# or Python bindings could be provided as an
extra package on top of the C API.

> I also have some doubts how to create an unique compilation that is
> suitable for all of the applications and the various needs.
> Can someone confirm that the usage of the different CRT heaps will not
> cause memory related problems when compiling the code using different
> compiler installations. (Is the GDAL C API capable to pass memory
> segments being allocated and released on different sides?)

Generally speaking if you use the C API I *think* there should be
no cross-heap / cross-runtime problems but I'm not 100% sure of this
myself.  I'm imagining shipping a core built with VC7.1.

> There are some further issues should also be considered, like:
> 
> 1. Provide support for WIN64 images

I'd like to suggest we put off WIN64 native support binaries till we
have a good handle on 32bit builds, and till WIN64 is in wider use.

> 2. Possible issues related to embedding manifests in a multi-compiler
> environment (VC2003, VC2005)

I think if we build with VC7.1 we don't need to worry about manifests.
If we were to build the core with VC8 I think we would want to embed the
manifests as the makefiles do now.  But I get quite confused about how
DLL searching works with manifests in the picture.

> 3. Controlling compiler related runtime dependencies (like the .NET
> framework version affinity of the package)

I presume this only becomes an issue at the c#/.net level, is that
right?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org