>>>>> Paul Kelly <[EMAIL PROTECTED]> 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? _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev