[GRASS-dev] compiling in osgeo4w - configure: error: *** Unable to locate zlib library

[Hamish]

Helmut wrote:
> >> i can confirm this with your recent changes in svn
> >> with r45429 etc. for grass6-develbranch.

Hamish:
> > fwiw, that needs to be reverted, then audited and real fixes
> > committed piecemeal. it's a collection of private patches and
> > hacks to get it to run on the osgeo4w stack, not project wide
> > solutions. e.g. it simply comments out a problematic autoconf
> > search for geos, and a bunch more like that.

Martin:
> I agree that some changes need to be fixed/reverted. Anyway
> 80% of changes are relevant, so I do not feel that it should
> be reverted all.

the danger if incomplete/problematic stuff is committed, then is
left in a "just commit it and we'll clean it up later" state, is
that it easily gets forgotten about and the brokenness remains in
svn.  As has happened here.

I'd agree it's a bit silly to revert the 80% G_free()s, but now
that I think about it more, that should be reverted too and then
recommitted with a proper commit log message explaining why the
change was needed (DLL spanning problems) as it's not at all
obvious and can't be commented in the code.


> The winGRASS packaging is broken for more then 10 days, I don't
> think that this commit made situation worse than it is now.

POV choice: broken wingrass nightly build vs. new bugs for all
GRASS builds... if wingrass needs special patches those should
go into mswindows/osgeo4w/ and be applied at build time.


re. the g.region patch, ideally osgeo4w would ship projects.h
until Frank is able to ship a new version of proj4 with the
pj_projects() fn exposed publicly, and we are able to adapt to
whatever that is. for now I'd prefer a patch to be applied at
build time to adding a #ifdef in the code, but maybe it is best
to put such things into grass's include/gprojects.h?
(tbc'd on the proj4 bug for that)


Hamish