Hi,
currently I am merging the recent PROJ4 updates into GRASS 5.1.
Due to the requirements of PROJ4/CVS we had to upgrade 'autoconf'.
Now, when running 'autoconf' on the configure.in of 5.1 I get:
autoconf
configure.in:39: error: possibly undefined macro: AC_MSG_ERROR
I am not sure if I should submit the generated configure to CVS
or fix something with 'autoconf' first.
The versions in use are (I am not root on this machine):
autoconf --version
autoconf (GNU Autoconf) 2.53
Written by David J. MacKenzie and Akim Demaille.
Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
automake --version
automake (GNU automake) 1.6.3
Written by Tom Tromey <tromey@redhat.com>.
Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
A quick google search didn't help too much.
Suggestions welcome,
Markus
Hello Markus
On Thu, 10 Apr 2003, Markus Neteler wrote:
Hi,
currently I am merging the recent PROJ4 updates into GRASS 5.1.
Due to the requirements of PROJ4/CVS we had to upgrade 'autoconf'.
An interesting anecdote: when I added the PROJ options to the configure
script for 5.0 it was my first experience using autoconf. Any 2.5x
versions I tried ran OK (sometimes there were warnings though) but the
configure script they generated wouldn't run; had errors somewhere halfway
down nowhere near my changes. So I downgraded to 2.13 as I could see it had
been used in the current configure script in CVS and it worked fine.
I didn't merge all my changes into 5.1 because I wasn't sure about the
different Makefile system. I actually think it would be a good idea to
remove the local copy of PROJ.4 from 5.1 and make the requirement of an
external libproj an absolute dependency. The Makefile for the proj library
in 5.1 would be quite simple then and only need to compile get_proj.c and
do_proj.c I think, along with the datum shift files and any other stuff.
We wouldn't need to set GPROJLIBOBJS and USE_PROJ in the configure script
then. And we wouldn't need the separate gproj_api.h; gprojects.h would
just unconditionally include proj_api.h from the external PROJ.4
installation.
Does this sound like a good idea? I can have a look at fixing it up after
the configure script is sorted out.
Paul
Hello Paul, developers,
On Thu, Apr 10, 2003 at 09:54:23AM +0100, Paul Kelly wrote:
On Thu, 10 Apr 2003, Markus Neteler wrote:
>
> currently I am merging the recent PROJ4 updates into GRASS 5.1.
> Due to the requirements of PROJ4/CVS we had to upgrade 'autoconf'.
An interesting anecdote: when I added the PROJ options to the configure
script for 5.0 it was my first experience using autoconf. Any 2.5x
versions I tried ran OK (sometimes there were warnings though) but the
configure script they generated wouldn't run; had errors somewhere halfway
down nowhere near my changes. So I downgraded to 2.13 as I could see it had
been used in the current configure script in CVS and it worked fine.
So you can compile the "Frank's" PROJ4 from CVS with autoconf 2.13?
For that fails (it asks for autoconf 2.5x!).
I didn't merge all my changes into 5.1 because I wasn't sure about the
different Makefile system.
It should be even easier to update than the Gmakefiles.
I actually think it would be a good idea to
remove the local copy of PROJ.4 from 5.1 and make the requirement of an
external libproj an absolute dependency. The Makefile for the proj library
in 5.1 would be quite simple then and only need to compile get_proj.c and
do_proj.c I think, along with the datum shift files and any other stuff.
We wouldn't need to set GPROJLIBOBJS and USE_PROJ in the configure script
then. And we wouldn't need the separate gproj_api.h; gprojects.h would
just unconditionally include proj_api.h from the external PROJ.4
installation.
Does this sound like a good idea? I can have a look at fixing it up after
the configure script is sorted out.
For me that sounds fine. On the one hand it's a dependency more, on
the other hand less synchonization work for us.
Markus