Sorry for raising this issue once again, but are there any plans
to switch to more recent versions of Autoconf?
Ivan Shmakov ha scritto:
Sorry for raising this issue once again, but are there any plans
to switch to more recent versions of Autoconf?
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?
All the best.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc
Recently at work we also switched to cmake from autotools, and life is much simpler now. I would gladly help if we do decide to switch.
A few benefits of cmake include generating native visual studio project and build files. Trivial way of generating dll libraries and linking in general. The same configuration files work on all platforms.
--Wolf
On 31.01.2008 15:57, 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?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?
All the best.
pc
--
<:3 )---- Wolf Bergenheim ----( 8:>
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
On Jan 31, 2008, at 12:00 PM, Paul Kelly wrote:
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?
As an end-user compiling GRASS, cmake is yet another requirement. I'm guessing that on other systems, and certainly OSX, developer tools don't include cmake, but do include the basic make and even autotools. And as you say GRASS' build system is already relatively simple. Personally, it doesn't matter (though I quietly resisted the Qgis transition for a while), as long as GRASS compiles.
As a (minimal) developer, I haved learned enough of the make system to do what I need to do. I don't look forward to learning a new system, even if it turns out to be simpler.
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.
An out-of-source build would be nice. Currently it's not an issue for me on OSX, since the Leopard linker has problem that is forcing me to build separately on Leopard and Tiger systems. But when that's fixed, I will build both the Tiger and Leopard binaries on Leopard, and not having to duplicate the whole source tree for each will be nice.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
The equator is so long, it could encircle the earth completely once.
Paul Kelly <paul-grass@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?
Ivan Shmakov wrote:
> ? 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.
The main problem with automake is that the Makefiles which it
generates are utterly illegible to anyone who isn't an automake guru.
Using high-level tools may decrease the amount of typing, but it
increases the amount of learning required; at least if you want to
understand your own project. If you write your own Makefiles, you need
to understand GNU make. If you use automake, you need to understand
both GNU make and automake.
> 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?
It should do. If something is reported not to work when
cross-compiling, it gets fixed.
There are a few steps which inherently need to be performed on the
target, e.g. generating the documentation requires running the
executables, which has to be done on the target (but you may as well
just copy the documentation from a native build; it's not like it
changes between platforms). Ditto for generating the fontcap file.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements <glynn@gclements.plus.com> writes:
>>> ? 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.
> The main problem with automake is that the Makefiles which it
> generates are utterly illegible to anyone who isn't an automake guru.
I don't think so. However, a decent knowledge of both the GNU
Make advanced features (e. g., VPATH or static pattern rules)
and the GNU coding standards is necessary.
> Using high-level tools may decrease the amount of typing,
And not only that. The use of high-level tools usually brings
uniformity. Which, in turn, decreases the amount of
``learning'' required.
With regard to Automake it means enforcing the GNU coding
standards on the build system, so that the user has to memorize
less intricacies about particular build systems.
> but it increases the amount of learning required; at least if you
> want to understand your own project. If you write your own Makefiles,
> you need to understand GNU make. If you use automake, you need to
> understand both GNU make and automake.
Indeed. Unfortunately, some users are trying to employ
high-level tools, but don't care to actually learn them, and
neither what they were designed for, neither how. There ain't
no such thing as a free lunch, though.
I'd call that a main problem with Automake.
[...]
>> One more question: does the current build system support
>> cross-compilation?
> It should do. If something is reported not to work when
> cross-compiling, it gets fixed.
> There are a few steps which inherently need to be performed on the
> target, e.g. generating the documentation requires running the
> executables, which has to be done on the target (but you may as well
> just copy the documentation from a native build; it's not like it
> changes between platforms). Ditto for generating the fontcap file.
Thanks.
Paul wrote:
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.
re. "stopping needless regeneration of HTML documentation on every
compile":
I am still not happy with the current solution. For example:
# help page updated from 2 days ago
$ cd vector/v.extract
$ svn up
U description.html
Updated to revision 29941.
$ make
[...]
make[2]:
`/usr/local/src/grass/svn/grass63/dist.i686-pc-linux-gnu/docs/html/v.extract.html'
is up to date.
[...]
(& the help page is not updated)
No, v.extract.html is not up to date. Only the top --html-description
part is up to date.
$ touch main.c
$ make
....
make htmlcmd
make[1]: Entering directory
[...]
.../../tools/mkhtml.sh v.extract ; mkdir -p
/usr/local/src/grass/svn/grass63/dist.i686-pc-linux-gnu/docs/html ;
/usr/bin/install -c -m 644 v.extract.tmp.html
[...]
(help page is updated)
Changes to either the module's G_parser() definition or
description.html should trigger a rebuild of the help page, somehow.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hamish wrote:
> 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.re. "stopping needless regeneration of HTML documentation on every
compile":I am still not happy with the current solution. For example:
# help page updated from 2 days ago
$ cd vector/v.extract
$ svn up
U description.html
Updated to revision 29941.
$ make
[...]
make[2]:
`/usr/local/src/grass/svn/grass63/dist.i686-pc-linux-gnu/docs/html/v.extract.html'
is up to date.
[...]
(& the help page is not updated)No, v.extract.html is not up to date. Only the top --html-description
part is up to date.
Changes to either the module's G_parser() definition or
description.html should trigger a rebuild of the help page, somehow.
The main problem is that not all modules have a description.html file,
so making description.html a prerequisite for .html files will result
in an error for those modules which don't have them.
We could manually add a dependency line for every module, which makes
either description.html or <module>.html a prerequisite, depending
upon which one the module has.
Or we could rename all description.html files to <module>.html (you
can't do the reverse, as that won't work where we have multiple
modules in a directory).
I'd prefer the latter, but the change has to be universal (i.e. no
exceptions) before we can add the <module>.html file as a prerequisite
to the rules in Html.make.
--
Glynn Clements <glynn@gclements.plus.com>