Re: [osgeo4w-dev] Current filesystem tree sucks!

[Ivan Lucena]

Frank, Mateusz,

I develop a GUI that suppose to be setup by the end user to work with whatever GDAL distribution they have. They just need to say where is folder where is the GDAL bin folder, where is the GDAL data folder and where is the GDAL plugins folder. That was designed to work with GDAL binary ZIP distribution and FWTools and that is how it was tested and released.

But now with OSGeo4w it became a little bit difficult to explain users how to setup the environment. It is not impossible, it is just complicated, depending on which GDAL version and plugin they want to use. It is not just "type gdal17" and everything is fixed for you.

End user's questions:

- If I have installed GDAL 1.7 why I still have GDAL 1.5 on OSGeo4w/bin? That should be *updated* to 1.7.
- Where is the "data" folder? OK I found it, actually I found another one. Which one should I use?

Note that they are end user and Windows users with serious command line disability :)  that is why I developed that GUI. What it does is basically build the command, send to the OS, capture stderr and stdout, cancels the process if asked to, etc. And it is configurable, you can add more commands and options at will.

Again. I can tell then how to make it work with OSGeo4W but it is hard to explain why things are the way they are.

Regards,

Ivan

 


>  -------Original Message-------
>  From: Mateusz Loskot <mateusz at loskot.net>
>  To: Frank Warmerdam <warmerdam at pobox.com>
>  Cc: osgeo4w-dev at lists.osgeo.org
>  Subject: Re: [osgeo4w-dev] Current filesystem tree sucks!
>  Sent: Sep 11 '10 13:00
>  
>  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
>  _______________________________________________
>  osgeo4w-dev mailing list
>  osgeo4w-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
>