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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
