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
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.
>
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 possi
: [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
e bindings.
Jason
*From:*Joaquim Luis [mailto:jl...@ualg.pt]
*Sent:* Friday, January 07, 2011 10:27 AM
*To:* Jason Roberts
*Cc:* 'Tamas Szekeres'; 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,
WI
2011/1/7 Jason Roberts
> 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
s Szekeres'; 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 pr
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
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 Prog
ables if
calling 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
20
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
2011/1/7 Jason Roberts
> 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
> scripts) to \Program Fi
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
script
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 "")
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 h
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
osgeo.org
Subject: Re: Fwd: Re: [gdal-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
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
2011/1/6 Jason Roberts
>
> 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 produced a weird problem
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 separately
2011/1/6 Christopher Barker
> 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). However we
could pro
inion.
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:
On 1/6/11 1:51 PM, Tamas Szekeres wrote:
2011/1/6 Christopher Barker
yup -- it seems long, descriptive file names would help, but that
doesn't seem to be the Windows way...
OS_X hard-codes the path to shared libs when linking, which causes its
own problems, but not these ones.
I think Jas
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 to
2011/1/6 Christopher Barker
> 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
> restricted to 8.
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 install
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
> Progra
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 p
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
policy
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
Does that sound like the right direction?
Jason
From: Tamas Szekeres [mailto:szeker...@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
2.Build an insta
2011/1/6 Jason Roberts
> 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 to modify the
> PAT
ean, standardized way to do that.
There are some innovations related to the "easy_install" thing I mentioned
earlier, but nothing has become standard in Python itself, at least with the
2.x releases.
Jason
From: Tamas Szekeres [mailto:szeker...@gmail.com]
Sent: Thursday, January 06
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 (!path.Contains(gdal_bin_pat
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 variabl
2011/1/6 Ari Jolma
>
> 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
http://trac.osgeo.org/gdal/browser/trunk/gdal/nmake.o
On 01/06/2011 01:38 PM, Tamas Szekeres wrote:
2011/1/6 Ari Jolma 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 those a couple of tim
2011/1/6 Christopher Barker
>
> On 1/5/11 3:12 PM, Tamas Szekeres wrote:
>
>> As far as I remember setting up the
>> following environment variables properly (in a command prompt) does the
>> right thing from arbitrary locations (at least when running the autotest
>> suite for GDAL):
>>
>> PROJ_L
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 solution
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 tree
2011/1/6 Ari Jolma
>
> 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 problem). Maybe I shoul
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 pac
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
>
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
PM
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/5 Jason Roberts
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
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
2011/1/5 Jason Roberts
>
> 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 and related files,
Barker
Cc: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
2011/1/5 Christopher Barker
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 alway
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 (simi
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
With regards to the comment above, while I'm not sure about the
objectives but I don't think the GDAL site would intend to
2011/1/5 Daniel Morissette
> 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 long (or lasts forever
2011/1/5 Christopher Barker
>
> 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 not sure about t
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 support.
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 entries)
2011/1/5 Christopher Barker
> 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 appropriate Windows executab
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
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: http://feeds2.feedburner
57 matches
Mail list logo
