Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Tamas Szekeres]

2011/1/7 Jason Roberts <jason.roberts at duke.edu>

> WIX looks like a great technology for building the installation package.
> I’ve never used it but I took a quick look and it seems to provide what is
> needed.
>
>
>

Jason,

I've already used WIX many times and I'm very satisfied with it.


> As I understand it, you are pondering whether it would be better to have
> GDAL in Program Files\OSGeo\GDAL or in Program Files\GDAL. Is it simply a
> question aesthetics or principle, in which it seems proper to put all OSgeo
> projects under Program Files\OSGeo, but there could be problems coordinating
> the efforts of multiple projects to adhere to that carefully and not mash
> each other’s files? If that summarizes the issue, then I’d recommend going
> with the more practical, less principled approach: put GDAL in Program
> Files\GDAL, and OSGeo4W in Program Files\OSGeo4W. It could get messy if both
> installers have to be able to create the Program Files\OSGeo directory but
> not necessarily delete it when they are uninstalled, because there could be
> another OSGeo project in there.
>
>
>
> Along those lines, I would suggest that if GDAL plans to support
> side-by-side installations of GDAL itself, then we need to contemplate
> carefully whether to use Program Files\GDAL\GDAL-X.Y or Program
> Files\GDAL-X.Y. I think either one would be ok, so long as whoever writes
> the installer thinks out all the side-by-side installation/uninstallation
> scenarios.
>
>
Just by thinking about the details if we implement a smart dll loader which
could in fact work with any locations to load the dll-s why do we require to
use a specific folder as the install location? The installer may create a
registry entry or a config file in a specific place where the necessary
dependencies are installed actually. The  loader would be responsible to
query for a compatible entry and use that location when loading the
dependent dll-s. If no entries found the loader would provide an error that
a dependent setup should also be executed.



>
>
> Another question, also already raised, is whether to have just two or all
> three version numbers in the installation directory. I think that question
> depends on whether you ever need to support bugfix releases installed
> side-by-side (e.g. 1.8.0 and 1.8.1), and also whether the bindings and other
> integrators will need to bind to specific bugfix releases or not. For
> example, if you guarantee that all 1.8.x releases will have compatible
> ABIs—that you will never introduce a change that will break the binary
> interface without increasing the minor build number—then it would be ok to
> just use X.Y in the directory name. But if that cannot be guaranteed, then
> you need to support X.Y.Z so that bindings and other integrators can locate
> the specific bugfix release that they are compatible with.
>
>
>

It would not be a problem in the scope of my comments above. The user could
install multiple versions anywhere and the loader would be responsible to
find out the corresponding version at run time.


> Regarding x86 vs. x64. The GDAL installer should follow the standard
> Microsoft convention. On an x64 machine, the x64 GDAL utils/libs should go
> in \Program Files and the x86 utils/libs should go in \Program Files (x86).
> The bindings and other integrators must be aware of x86 vs. x64 and locate
> libs from the correct directory.
>
>
>
> I agree that calling SHGetSpecialFolderLocation with an appropriate CSIDL
> is an appropriate way to find the Program Files directory (addressing issue
> noted by Joaquim and others that Program Files is localized). It is probably
> ok to use the ProgramFiles and ProgramFiles(x86) environment variables if
> calling the Win32 API is not easy for particular bindings.
>
>
We could probably implement the loader in C an use SWIG to map the functions
to the various languages. The implementation would be the same for all
languages in this regard.
The only issue here is that where to place the loader.dll (providing the
core implementation) which would also rely on the Windows dll search rules.
For python you could easily say to create a pyd installed along with the
python files, but in may not be so trivial for the other languages. I'm
tending to think that this part should probably be implemented in a generic
way (which doesn't change frequently) and be installed in a common folder
available in the PATH.

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110107/b68f5485/attachment-0001.html