On 27/03/09 07:18, Michael Barton wrote:
Also, while the osteo4w installer is nice for individual installs, it is
problematic for institutional lab installs, where IT managers want to
have stand alone apps that they can test, install, and remove rather
than a suite of apps in a package installe
On 27/03/09 10:30, G. Allegri wrote:
> In any case the questions remain:
1 - continue to build grass with MingW?
1a: build it against MinGW built libs (not osgeo4w)?
1b: build it against vc built libs (osgeo4w)?
2 - build Qgis with vc (osgeo4w) and solve the bindings problems wi
Ok Markus. I'm sorry for pressing... My hope is to do not have a
broken community around this issues. I would like to come to a common
thought, and work for a coherent and clear roadmap. Probably it's me
(and the users) that don't have it clear, while it is for all of the
developers: who is doing w
Jachym,
I have to echo what Michael is saying about the Windows installer. In a
government enterprise environment, I doubt the present osgeo installation
format would be accepted. A stand-alone msi package would be better.
Another question with the osgeo installer, would the installation of th
Anyway, IIUC Glynn and Jurgen:
the problem on mixing MSVC and MinGW built things (at C level) is
just a problem of a clean memory management (malloc/free). So, my
question is: would changing the build system (GNU make -> cmake) solve
this? Or they're unrelated things?
2009/3/27 G. Allegri :
> Ok
> I am not aware of any postings in this regard from Marco.
> Please point us to that to better understand the issues he found.
I've just asked him if he can partecipate to the discussion to explain this...
> Question: Did you try to update the installer from Marco? Maybe
> it works out of the bo
Hi Giovanni,
On Fri, 27. Mar 2009 at 12:36:43 +0100, G. Allegri wrote:
> the problem on mixing MSVC and MinGW built things (at C level) is
> just a problem of a clean memory management (malloc/free). So, my
> question is: would changing the build system (GNU make -> cmake) solve
> this? Or they'r
Thanks Jef. So, fixing the memory issues in grass code isn't
avoidable. I'll go on with this (after g.proj, db binaries, v.in.ogr,
etc.), because probably this will solve the problems that users are
facing from within QGis (various crashes when using the grass plugin).
So the real limitation for th
On Fri, Mar 27, 2009 at 3:05 PM, G. Allegri wrote:
> Thanks Jef. So, fixing the memory issues in grass code isn't
> avoidable.
I think that several developer are willing to help here once understood
the problems which means...
> I'll go on with this (after g.proj, db binaries, v.in.ogr, etc.),
#537: g.proj.exe crashes on Windows Vista (osgeo4w)
--+-
Reporter: giohappy | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major
Thanks Moritz,
I'm glad to see that this is possible at least, though it is by no
means obvious. I will try to find a place to archive this information
as I will be again doing a lab course later this spring. The fact that
critical information for creating a stand-alone package is buried in
#537: g.proj.exe crashes on Windows Vista (osgeo4w)
--+-
Reporter: giohappy | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major
On Fri, Mar 27, 2009 at 4:17 PM, Michael Barton wrote:
> Thanks Moritz,
>
> I'm glad to see that this is possible at least, though it is by no means
> obvious. I will try to find a place to archive this information as I will be
> again doing a lab course later this spring. The fact that critical
>
Thanks Markus,
This will make the information more accessible.
Michale
On Mar 27, 2009, at 8:41 AM, Markus Neteler wrote:
On Fri, Mar 27, 2009 at 4:17 PM, Michael Barton > wrote:
Thanks Moritz,
I'm glad to see that this is possible at least, though it is by no
means
obvious. I will try to
14 matches
Mail list logo
