On 1/6/2011 4:25 PM, Joaquim Luis wrote:
By the way, isn't there some new stuff about side by side installs
or something -- that's supposed to help dll hell?
I think you are referring to the manifests but here also MS has
changed their mind (aleluia). VC2010 doesn't have them anymore which IMO
2011/1/7 Jason Roberts jason.robe...@duke.edu
Thanks for your thoughts. Based on them, I'd recommend the following two
things be created.
1. GDAL windows installation program, or at minimum, a wiki page that says
how to install the GDAL libraries and utilities (executables and Python
Frank,
I would suggest building it as an installer .exe, perhaps using NSIS as
I did for FWTools, or perhaps the method mentioned by Jurgen produces
a nice installer.
If possible, I would suggest the final output be a .msi (Windows Installer
package) rather than a .exe. In an effort to make
the Win32 API is not easy for particular bindings.
Jason
From: Tamas Szekeres [mailto:szeker...@gmail.com]
Sent: Friday, January 07, 2011 5:26 AM
To: Jason Roberts
Cc: Frank Warmerdam; gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/7 Jason Roberts
On 07-01-2011 15:07, Jason Roberts wrote:
Tamas,
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.
As I understand it, you are pondering whether it would be better to
have GDAL in
On 11-01-07 10:07 AM, Jason Roberts wrote:
put GDAL in Program Files\GDAL, and
OSGeo4W in Program Files\OSGeo4W.
Jason,
I would note that OSGeo4W installs in C:\OSGeo4W by default, and there are
no plans currently to change this. OSGeo4W will continue to use it's
internal copy of GDAL.
It
'; gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 07-01-2011 15:07, Jason Roberts wrote:
Tamas,
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
2011/1/7 Jason Roberts jason.robe...@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
: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-07 10:07 AM, Jason Roberts wrote:
put GDAL in Program Files\GDAL, and
OSGeo4W in Program Files\OSGeo4W.
Jason,
I would note that OSGeo4W installs in C:\OSGeo4W by default, and there are
no plans currently to change this. OSGeo4W will continue to use it's
On 1/6/11 7:55 PM, Frank Warmerdam wrote:
One question not discussed is whether GDAL should be minimalist or
maximalist. That is, do we want to include as many formats as possible
despite the fact that it drags in lots of supporting libraries?
+1 for Maximalist. We want as many things as
Hi Chris,
On Fri, 07. Jan 2011 at 12:03:47 -0800, Christopher Barker wrote:
On 1/6/11 8:23 PM, Jürgen E. Fischer wrote:
You get a desktop link and a start menu entry that both opens a command line
window from where you can use GDAL
very nice.
and start python with gdal available.
what
On 01/06/2011 01:18 AM, Tamas Szekeres wrote:
Chris,
Good points below, but having the compiled gdal binaries (and the
binaries of the dependent libraries) in hand, which is the right way
to install those files on Windows? (Assuming we don't provide
python.exe and the related files in the
2011/1/6 Ari Jolma ari.jo...@gmail.com
GDAL is available but again typically as MS compiler builds - which should
not be a problem in theory because the bindings use it through the C API.
I've tried to use those a couple of times without luck (compiling the
bindings in MinGW was the
Three months ago I put an announcement on the MapServer-Users list about
a shell script I wrote to compile the whole MapServer-GDAL-PostGIS-PLR
suite, with and without PHP/Python, in a separate user directory using
only two commands. Separate installations can coexist in separate
directory
Jason,
I appreciate the expertise for all of you along with this thread, I could
already gather quite some useful information from here for this reason. I
must mention that my programming practice in Python can be considered as
zero, this is the main reason that my issues may have trivial
On 01/06/2011 01:38 PM, Tamas Szekeres wrote:
2011/1/6 Ari Jolma ari.jo...@gmail.com mailto:ari.jo...@gmail.com
GDAL is available but again typically as MS compiler builds -
which should not be a problem in theory because the bindings use
it through the C API. I've tried to use
2011/1/6 Ari Jolma ari.jo...@gmail.com
By the age I meant that the SDK packages are old releases (from 1310 to
1600 and not trunk for example - do I understand the release names
correctly?)
Ari,
Those numbers are MSVC compiler numbers (according to
On 01/06/2011 03:25 PM, Tamas Szekeres wrote:
Assuming we install the gdal-perl modules in a standard location (not
sure where it is), do we have a common mechanism in the perl runtime
to find the dependent dlls without having to violate system wide
settings (like the PATH environment
Ari
The only wokaround which is satisfactory to me is to set the required
enviroment at run time before the gdal bindings are used. In csharp we can
do something like:
string path =
Environment.GetEnvironmentVariable(PATH);
if
become standard in Python itself, at least with the
2.x releases.
Jason
From: Tamas Szekeres [mailto:szeker...@gmail.com]
Sent: Thursday, January 06, 2011 7:24 AM
To: Jason Roberts
Cc: gdal-dev@lists.osgeo.org; Christopher Barker
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Jason Roberts jason.robe...@duke.edu
2.Build an installation package as above. Have it install the GDAL
DLLs as a subdirectory of the osgeo directory, e.g.
C:\PythonXY\Lib\site-packages\osgeo\bin. Modify gdal.py to set
os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir
...@gmail.com]
Sent: Thursday, January 06, 2011 11:07 AM
To: Jason Roberts
Cc: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/6 Jason Roberts jason.robe...@duke.edu
2.Build an installation package as above. Have it install the GDAL DLLs
Lots of stuff in this thread, I'll try to contribute what I can inline:
On 1/6/11 2:15 AM, Ari Jolma wrote:
When I started there was only ActivePerl for Windows that was usable,
but it turned out impossible for me to use because they use MS
compilers. Now there is Strawberry Perl, which I might
Tamas,
In Perl the programmer can postpone loading the external DLL required by
a module. Thus a similar approach is viable in Perl. But that's not how
it's usually done. If you have a DLL in a system that is meant for
shared use then it should be in the system PATH. Thus I believe the
On 1/6/11 12:13 PM, Ari Jolma wrote:
If you have a DLL in a system that is meant for
shared use then it should be in the system PATH. Thus I believe the
policy should be to set the PATH if GDAL is installed into a system
I notice on my system, the dll is gdal17.dll
That is, the version is
Chris,
Here are some comments on specific parts of your mail:
me neither, with Python (or anything Windows, for that matter). Maybe
Jason knows better, but I *think* we should be OK with a standard
location for GDAL. But could you have:
Program Files\GDAL\1.6\gdal.dll
and
Program
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided to distribute the GDAL binaries using an
2011/1/6 Christopher Barker chris.bar...@noaa.gov
I notice on my system, the dll is gdal17.dll
That is, the version is part of the file name, so there shouldn't be a
problem with different versions installed in the PATH.
WE could even use a longer filename, like *nix systems, we're not
On 11-01-06 04:42 PM, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided
On 1/6/11 1:51 PM, Tamas Szekeres wrote:
2011/1/6 Christopher Barker chris.bar...@noaa.gov
This is where a typical dll hell problem is starting. The application is
happy to load a common dll let's say a gdal17.dll, zlib1.dll,
libcurl.dll whatever, but is not the same at it is expected to be (for
.
Thanks,
Jason
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Thursday, January 06, 2011 5:01 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-06 04:42 PM
2011/1/6 Christopher Barker chris.bar...@noaa.gov
yup -- it seems long, descriptive file names would help, but that doesn't
seem to be the Windows way...
It would be true, but it's not a common practice of the libraries currently
(assuming we keep the original dll name of each dependency).
On 11-01-06 05:10 PM, Jason Roberts wrote:
Frank,
Thanks for sharing your opinion. I do have one question that I hope you will
weigh in on. Which of the following two options seems better to you:
1. The GDAL libraries (possibly accompanied with executable programs) are
installed as a
2011/1/6 Jason Roberts jason.robe...@duke.edu
So #3 is not better by virtue of not having to modify the bindings; it does
have to modify the bindings. But #3 is appealing because setting the PATH
from Python code sometimes has weird issues. For example, when I tried it in
my code, it
On 06-01-2011 21:42, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided
-dev] FWTools and GDAL 1.7.0
On 11-01-06 05:10 PM, Jason Roberts wrote:
Frank,
Thanks for sharing your opinion. I do have one question that I hope you
will
weigh in on. Which of the following two options seems better to you:
1. The GDAL libraries (possibly accompanied with executable programs
1.Modify the makefiles for your SDK so that it runs
release--dev\gdal\swig\python\setup.py with the bdist
--formats=wininst option. This will produce an installation program such as
gdal-1.7.3.win32-py2.5.exe. This is what the user will run to install the
Python bindings together with a
On 1/6/11 3:03 PM, Joaquim Luis wrote:
Also a word about the best practice on Windows. I really don't see
anything not even good in that practice to put them in Program Files.
Having directories with blanks in their name give nothing but future
problems when running command line programs (I have
Perhaps that's why the standard place for Python is NOT in Program
Files
Yes, there is wisdom.
That being said, Program Files does seem to work fine for me most of
the time.
And for the (1 - most) times that it didn't work you knew how to fix
it (enclosing the full path with ) but
On 11-01-06 06:43 PM, Jason Roberts wrote:
Frank,
Thanks for your thoughts. Based on them, I'd recommend the following two
things be created.
1. GDAL windows installation program, or at minimum, a wiki page that says
how to install the GDAL libraries and utilities (executables and Python
Hi all,
for what is worth also for me the simplicity of FWTOOLS wins.
Best regards,
andrea
-
Andrea Borruso
email: aborr...@tin.it
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed:
On 1/5/11 3:41 AM, iomeneandrei wrote:
for what is worth also for me the simplicity of FWTOOLS wins.
FWTools is nice, but I think with OSgeo4win, not really important.
However, for simplicity, a one-click installer for just GDAL/OGR for
Windows, complete with command line tools and ready for
2011/1/5 Christopher Barker chris.bar...@noaa.gov
However, for simplicity, a one-click installer for just GDAL/OGR for
Windows, complete with command line tools and ready for use with the python
bindings (and others language bindings?) would be great.
I've found it painful to find
On 11-01-05 12:44 PM, Tamas Szekeres wrote:
I also wanted to include these files in an installer (or multiple
installers) but at the moment I don't see the real benefit of this over
extracting a single zip package, since these libraries don't require
significant preparation (like regkey
On 1/5/11 9:44 AM, Tamas Szekeres wrote:
Supporting multiple vesions (development/stable branches/releases,
x32/x64, multiple MSVC CRT dependencies) is quite a difficult task in a
single installer.
yes, a Major pain. I don't know that we need a single installer, but
there is a lot to
2011/1/5 Christopher Barker chris.bar...@noaa.gov
1) It would be nice to have binaries for the latest release front and
center at the main GDAL site -- having to poke around to find Tamas's site
is not a big deal, but not always obvious.
Chris,
With regards to the comment above, while I'm
2011/1/5 Daniel Morissette dmorisse...@mapgears.com
I agree with you, but it seems that an [OK] button (even if it doesn't do
anything) makes Windows users feel so much better. :)
Daniel,
:-) And sometimes we wonder what a heck is being done behind an OK button
on Windows which takes so
It may well be that GDAL has too many different use cases to even have a
standard install, but...
On 1/5/11 1:37 PM, Tamas Szekeres wrote:
2011/1/5 Christopher Barker chris.bar...@noaa.gov
1) It would be nice to have binaries for the latest release front
and center at the main GDAL
Folks,
Wow, what a lot of discussion.
From my perspective, I'm pleased with Tamas' provided binaries as a source
for developers who want a GDAL SDK for a particular compiler version and
choice of win32/win64.
I like Jurgen's idea of building a stock GDAL binaries package with an
installer
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Christopher Barker chris.bar...@noaa.gov
1) It would be nice to have binaries for the latest release front and center
at the main GDAL site -- having to poke around to find Tamas's site is not a
big deal, but not always obvious
2011/1/5 Jason Roberts jason.robe...@duke.edu
Right now, to install the latest GDAL for Python on Windows, the user has
to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find
the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into
find the GDAL binaries
Chris,
Good points below, but having the compiled gdal binaries (and the binaries
of the dependent libraries) in hand, which is the right way to install those
files on Windows? (Assuming we don't provide python.exe and the related
files in the package)? I mean which install actions should be done
@lists.osgeo.org; Christopher Barker
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Jason Roberts jason.robe...@duke.edu
Right now, to install the latest GDAL for Python on Windows, the user has to
download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find
On 1/5/11 2:32 PM, Frank Warmerdam wrote:
From my perspective, I'm pleased with Tamas' provided binaries as a source
for developers who want a GDAL SDK for a particular compiler version and
choice of win32/win64.
yes, those are great!
Like some others, I'm also confused by the correct way
Hi Frank,
On Wed, 05. Jan 2011 at 17:32:42 -0500, Frank Warmerdam wrote:
Is there someone that wants to take on producing official GDAL binaries
from OSGeo4W with a self installer sort of similar to FWTools, likely
using the mechanism Jurgen described? I'm interested, but interest hasn't
Hi Frank
I personally will be happy to see FWTOOLS updated at least for major Gdal
releases. I find it to be a much simpler way to distribute Gdal to my end users.
I agree that OSGeo4W is more complete, but I think that for many users the
simplicity of FWTOOLS wins.
Thanks
Yehiyam Livneh
From:
56 matches
Mail list logo
