[osgeo4w-dev] Current filesystem tree sucks!

[Mateusz Loskot]

On 11/09/10 08:39, Frank Warmerdam wrote:
> On Sat, Sep 11, 2010 at 2:21 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
>> 2) User configures 1.7.0 as selected for linking/runtime:
>>
>> update-alternatives.bat --install gdal-1.7.0
>>
>> 3) update-alternatives.bat performs:
>>
>> a) disables current version removing all files
>> b) enabling gdal-1.7.0 copying all files from local cache
>> c) no need to update PATH or any other OSGeo4W environment.
>>
>>
>> Shortly, my message is: please, keep the filesystem tree a) unified
>> and b) constant.
> 
> Mateusz,
> 
> First let me know that any given time there can be
> applications within OSGeo4W linked against different
> versions of GDAL so it is necessary that the GDAL DLL
> for multiple versions exist at once (potentially).  Luckily,
> since they are named with the major version they can
> coexist in the C:\OSGeo4W\bin directory safely.

So, naming convention should be sufficient to solve versions
coexistence issues.

> Second, there is also a need for the supporting GDAL
> data files (.csv files, etc) from each usable version.  These
> must be in some non-overlapping location in the file system.

This one is tricky indeed.

> Then we get to more debatable points, like whether it
> is helpful to have the developer support materials or
> documentation for more than one version at a time.  I
> don't have a particularly strong position on whether this
> is needed or not, but I don't really understand the
> problem that you encounter.   I have made some
> (perhaps not complete enough) effort to ensure that
> the apps\gdal<version> directories are laid out similarly
> to how files would appear in C:\OSGeo4W so that you
> can just change a root macro/variable to pull from one
> of the non-default versions.

Does it mean arrangement of GDAL in apps\ folder
is a kind of convention which will be followed in future
and by other packages as well?

> I will add that it is not very easy for us to uninstall
> and reinstall packages from bat files without adding
> an explicit dependency on the perl based apt interface
> to packages.
> 
> Lacking an understanding of the need you are trying
> to express I am not to keen on taking action.

Users configure Visual Studio project files and makefiles,
write CMake macros, and similarly to how autotools relies
on Linux unified filesystem, those configurations maintained
by Windows users rely on OSGeo4W layout.
If there is no well-defined and described unification of OSGeo4W
filesystem, then it looks more like razzle-dazzle sandbox
than usable packaging.

I, as author of CMake macros, try to support OSGeo4W as standard
distribution of GIS (and not only GIS) packages for Windows and
I'm having problems in lack of bin, lib, include paths maintenance
on OSGeo4W side. Potential of OSGeo4W is fantastic as the soft provider.

I do read and I do understand the difficulties you've explained, but I
still think it would be good to try solving this problems and
preserve unified paths.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org