[Gdal-dev] Proposal for Unified Windows Binaries

Tamas Szekeres szekerest at gmail.com
Sun Apr 15 18:48:08 EDT 2007


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

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 would also keep on providing the related dll-s (like proj.dll) in
the package to support a ready to use installation.

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?)
Which default options to use the makefile? In this regard I consider
that the GDAL project is in a better shape than mapserver for
instance. As a raw example ms4w defines the USE_PHP_REGEX option which
prevents from the option to use regex with these binaries in an non
PHP environment at all.

There are some further issues should also be considered, like:

1. Provide support for WIN64 images
2. Possible issues related to embedding manifests in a multi-compiler
environment (VC2003, VC2005)
3. Controlling compiler related runtime dependencies (like the .NET
framework version affinity of the package)

Generally speaking it should be made clear how to reproduce a
particular binary representation from the corresponding sources.
(Without using undocumented inhouse hackings/scripts/file locations
for example).

Best regards,

Tamas




2007/4/15, Howard Butler <hobu at iastate.edu>:
> All,
>
> I think the time has arrived for us work toward releasing Windows
> binaries that coincide with software releases.  Numerous projects,
> notably WorldWind, Python Cartographic Library,  GeoTools/GeoServer,
> and many others are starting to more widely take advantage of all the
> hard work the swig bindings maintainers have been doing.   There are
> currently a number of folks generating Windows binaries, most notably
> FWTools and MS4W.
>
>  From a user's perspective, it is almost impossible to mix and match
> the drivers and features (scripting bindings, Python utilities, etc)
> that you might need if you want to do anything out of the ordinary
> for each distribution.  Each distribution also has a very different
> aim, with MS4W mostly tracking releases and FWTools covering the
> bleeding edge.  As a purveyor of exotic drivers (ArcSDE), the
> different distributions makes it hard for me to provide support, even
> though my driver can be built as a plugin, because of the need to
> match up linkages against each distribution.
>
> I think an "official" Windows GDAL release should have the following
> traits:
> - All optional drivers built as plugins and all other drivers built in
> - No scripting bindings
> - No Python utilities
> - Include the .lib files
>
> Instead of a monolithic kitchen sink approach, I think it might be
> better to provide the basic building blocks, which will allow
> developers to start from the same base and augment from that.  For
> example, with "GDAL Base," we could provide the Python bindings and
> utilities as an installable package that targets each Python version
> (same for .NET bindings, Java, and so on).
>
> Thoughts?
>
> Howard
>
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>



More information about the Gdal-dev mailing list