[GRASS-dev] Autoconf 2.13

[Ivan Shmakov]

>>>>> Paul Kelly <paul-grass at stjohnspoint.co.uk> writes:

 >>> 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?

	The support for the old version will most probably be dropped
	sooner or later.  I cannot say for sure what would it mean for
	GRASS, but I believe that the cooperation with the GNU Autotools
	folks will actually lighten the burden of maintaining the build
	system for the GRASS developers.  And such a cooperation implies
	the use of a newer version of the tool.  (And would you care for
	a user still using GRASS 6.0.2?)

 > --- I've no idea how much work this would involve?

	I've no idea as well, but probably a lot.  I'll investigate on
	it as the time will permit.

	If there'd be a consensus on moving to a newer Autoconf version,
	I'd like to open a Trac ticket for it.

 >> 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.

	Although it became common to blame GNU Autotools for sins of
	various sorts, out of my personal experience I could say that it
	actually helped me a lot to simplify the build systems for the
	various packages I had to build.  (Alas, saying this once again
	will probably make me the public enemy number one.)

	I had to study the documentation, though.

 > 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?

	I'd like to see that, too.

 > 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.

	I'll try to take a look at these issues.

	One more question: does the current build system support
	cross-compilation?