[GRASS-dev] Re: [GRASS-user] g.xlist/g.xremove addons (C version of g.mlist/g.mremove)

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>>> I've just uploaded g.xlist and g.xremove (C implementations of
 >>>> g.mlist and g.mremove, no dependency on g.list/g.remove) to
 >>>> grass-addons/general.  To compile these addons, you need POSIX
 >>>> regex(3) functions.  They are super fast (native speed of
 >>>> g.list/g.remove)!  Please test these modules.

 >> [...]

 >>>> If these changes to libgis (ls.c, join.c, gisdefs.h, POSIX regex)
 >>>> are acceptable, g.m?(list|remove) might be substituted with these
 >>>> modules (?).

 >>> The existing scripts cannot be removed unless the C versions can be
 >>> made to work on all platforms (I daresay there's a regex library
 >>> for Windows, but we still need configure tests, etc).

 >> BTW, Autoconf allows for the parts of the package to be configured
 >> by independent `configure' scripts (AC_CONFIG_SUBDIRS.)  Could the
 >> splitting of the top-level `configure' script be considered for
 >> GRASS?

 > Personally, I don't see that there is much to be gained by doing
 > this.

 > It's not as if different parts of GRASS really are separate packages.
 > Everything depends upon libgis,

	Which, fortunately, hasn't to be tested by configure.

 > and much of it depends upon e.g. GDAL.  So it's likely to be more
 > reliable if a single configure script considers everything as a
 > whole.

	I see your point.  However, it's not like that all the GRASS
	code depends on the same set of libraries.  (Does libgis depend
	on Python, or OpenGL, for instance?)

	Anyway, I'm primarily concerned with porting configure.in
	(aclocal.m4) to Autoconf 2.50+, and, to a somewhat lesser
	extent, with the readability of these.  And AC_CONFIG_SUBDIRS
	seemingly offers some help with respect to these tasks.