[GRASS-dev] Autoconf 2.13

Paul Kelly paul-grass at stjohnspoint.co.uk
Thu Jan 31 13:00:43 EST 2008


On Thu, 31 Jan 2008, Paolo Cavallini wrote:

> Ivan Shmakov ha scritto:
>> 	Sorry for raising this issue once again, but are there any plans
>> 	to switch to more recent versions of Autoconf?

I didn't think so - we've found autoconf 2.13 to work well for us. Would 
you be able to give a brief summary of the benefits of re-writing 
configure.in/aclocal.m4 to use a different autoconf version? --- I've no 
idea how much work this would involve?


> BTW: I followed the switch of qgis, from automake to cmake, and I think
> it was a good success (*much* less bloody than I expected). Now
> compilation is way smoother and faster.
> Would it be reasonable to do the same for GRASS?

?
GRASS doesn't use automake, so I'm not sure what you mean here. I'm sure 
if we *were* using automake, we'd also be quite keen to move away from it 
towards something simpler and better! IMHO the GRASS build system is 
refreshingly simple to understand compared to other projects that use 
complex automake, libtool etc.-based systems. Again, would you be able to 
give a brief summary (for those unfamiliar with cmake, such as myself) of 
what the benefits of cmake over GRASS' current build system might be?

Regarding problems with GRASS' system - I am aware of the need to simplify 
the platform checks in the SC_CONFIG_CFLAGS macro - see:
http://lists.osgeo.org/pipermail/grass-dev/2006-December/027945.html
http://lists.osgeo.org/pipermail/grass-dev/2006-December/027970.html
and it would be nice to be able to use an alternative build directory (not 
necessarily the top-level of the source), like the alternative build 
system in 5.3/5.4 allows, but IMHO it's really not that bad at present. 
There were also a lot of improvements and tidying recently with regard to 
making parallel builds work and stopping needless regeneration of HTML 
documentation on every compile.

Paul



More information about the grass-dev mailing list