I can confirm this with today's CVS. It's been out there for several days now.
Must be connected with recent changes to PROJ.4 handling at configure (see
recent archives for details).
FYI, if you set the new configure switch --with-proj-share correctly (e.g. on
my box its' "= /usr/local/share/proj/") the warnings are gone.
Propably the PROJ.4 share dir cannot be autodetected any longer by Grass for
some good reason, that's why the new switch.
I don't know if to expect problems due to the warning above. Since I have
noticed it I've been using --with-proj-share and all is ok.
Closing report. Re-open if needed.
Best,
Maciek
-------------------------------------------- Managed by Request Tracker
guest user via RT wrote:
I can confirm this with today's CVS. It's been out there for several days now.
Must be connected with recent changes to PROJ.4 handling at configure (see
recent archives for details).
FYI, if you set the new configure switch --with-proj-share correctly (e.g. on
my box its' "= /usr/local/share/proj/") the warnings are gone.
Propably the PROJ.4 share dir cannot be autodetected any longer by Grass for
some good reason, that's why the new switch.
The --with-proj-share switch replaced the autodetection code. With the
autodetection, if the file wasn't in either of the two directories
which the autodetection code tried, you lost.
Arguably, the two should be combined, so that if you don't specify
that switch (i.e. $with_proj_share is the empty string), it tries a
few common locations.
OTOH, with autodetection, there's always the possibility of it
autodetecting the wrong version of a file. Forcing the user to specify
the exact location eliminates that problem.
We don't do autodetection for libraries or header files because, when
we did, it regularly used to autodetect incompatible headers
(primarily, detecting OS headers in /usr/include when gcc should be
using its own versions from the gcc-lib directory), resulting in
confusing behaviour which often took a fair amount of time and effort
to identify.
--
Glynn Clements <glynn@gclements.plus.com>