[osgeo4w-dev] Support for the WIN64 binaries

[Tamas Szekeres]

2008/3/3, Frank Warmerdam <warmerdam at pobox.com>:
> I believe there are problems with having more than one non-ABI
>  compatible version of a package in OSGeo4W.  For instance, normally all
>  DLLs go in C:\OSGeo4W\bin.  If PROJ 4.5.0 and 4.6.0 were not ABI compatible
>  then there would be no easy way to have them co-exist - in fact, generally
>  two versions of a package can't coexist in OSGeo4W.
>
>  For Win64 I propose we work around this by essentially having a full
>  subtree in C:\OSGeo4W\win64 but this is really a whole distinct environment.
>  We aren't really sharing anything with the rest of the OSGeo4W environment
>  except for the installer.
>

Frank,

I think the same way would also work with the development version. We
should just copy these files in a different branch, like
C:\OSGeo4W\dev\ as a different environment just as for the Win64
packages. When the developer would decide to use this, she would
probably apply something like 'set PATH=C:\OSGeo4W\dev\bin;%PATH%'
before running the files or we could provide a dedicated Command
Prompt to pick up these environment variables properly.

Unlike FWTools you would only copy the real 'bleeding edge' stuff into
this directory. The other support libraries could be picked from the
stable packages automatically. Moreover you could specify that your
'bleeding edge' package eventually depends on a stable package if
needed.
I don't think if this approach would be less valuable than maintaining
a separate FWTools installer. I can imagine how the folks will get
confused and start copying the files over, or changing the PATH
between these packages in their environments and report a number of
funky issues in various mailing lists.  Wouldn't it be better to
separate the development stuff in a different directory and establish
dependencies to the existing osgeo packages?

Obviously you would have to check in your local sandbox how these
packages in the development branch can co-operate with regards of the
ABI before submitting those in the osgeo repository. But I think it's
not more than you would normally do with FWTools in general.

>  But, for instance, there is no easy way to make GDAL 1.5 and GDAL 1.6(trunk)
>  coexist in OSGeo4W.  While we can have distinct names for the main DLLs
>  (GDAL15.DLL and GDAL16.DLL), the plugins are not distinguished in this
>  way.  Neither are the include files, stub library or share/gdal data files.
>

I think these all would go to the /dev directory as well and the
plugins can work properly by setting the proper environment, or using
some other project dependent mechanisms (like placing the plugins
inside the /gdalplugins subdirectory of the application directory)

>  I think that trying to host binary incompatible versions of libraries in
>  OSGeo4W would be a mistake at this point ... over complicating things before
>  we even get going.
>

I think the real confusion is to have different installations having
the same files in the system. There have been a couple of questions in
the lists about the concept behind the _fw suffix in some of the
FWTools files for example, that might also originated from these
issues.

>  My vision of OSGeo4W is that it is stable and ready for use by end users.
>  I would prefer to see latest-and-greatest builds offered to users a
>  different way.  Possible project produced separate installers that might still
>  use parts of osgeo4w for base packages.
>

I would rather consider OSGeo4W as the common repository to provide
the Windows binaries of the various osgeo projects in an unique way.


Despite of my optimistic feeling above my real concern is how to have
the same package with different crt depencencies co-exit in the
system. Or can we force all of the packages compile using the same
compiler eg. VC8 for example. In my particular case I would probably
provide the C# bindings targeting the .NET FrameWork 2.0 that would
imply to use msvcrt80 definitely. In this case I would probably mark
this package dependent on the VC8 version of the gdal package since
using the VC7 version of the gdal in this case may behave
unexpectedly.

Best regards,

Tamas