Extension development - Revision history

⚠️Wenzeslaus: move to trac

2014-01-29T02:50:41Z

move to trac

← Older revision		Revision as of 02:50, 29 January 2014
Line 1:		Line 1:
			{{MoveToTrac}}

			''Information outdated, more a historical document but there is still a place for this topic.''

	= General =		= General =

Neteler: Category: Development

2007-10-23T07:04:16Z

Category: Development

← Older revision		Revision as of 07:04, 23 October 2007
Line 38:		Line 38:

	''[...in progress... more to come...]''		''[...in progress... more to come...]''

			[[Category: Development]]

⚠️Kyngchaos: add makefile notes

2007-10-23T03:59:38Z

add makefile notes

← Older revision		Revision as of 03:59, 23 October 2007
Line 6:		Line 6:

	* [[Development GEM]] - Current GEM SVN setup		* [[Development GEM]] - Current GEM SVN setup
			* [[GRASS 6.3 Feature Plan]] - backreference - hopefully extension compilation can be done for 6.3
	* [[GRASS 7 ideas collection#Conceptual Changes\|GRASS 7 Conceptual Changes]] - formalizing a user GRASS prefs and addons dir		* [[GRASS 7 ideas collection#Conceptual Changes\|GRASS 7 Conceptual Changes]] - formalizing a user GRASS prefs and addons dir

Line 23:		Line 24:

	In 6.3CVS, the Makefiles are now installed. With a little Makefile cleanup, and a few extra necessary items installled (demolocation and a couple tools), an installed GRASS can support compiling an extension without needing the full GRASS source, and without needing any extra module setup (as is needed currently by GEM-enabled modules). A standard GRASS module Makefile is all the would be needed.		In 6.3CVS, the Makefiles are now installed. With a little Makefile cleanup, and a few extra necessary items installled (demolocation and a couple tools), an installed GRASS can support compiling an extension without needing the full GRASS source, and without needing any extra module setup (as is needed currently by GEM-enabled modules). A standard GRASS module Makefile is all the would be needed.

			= Makefiles =

			Some notes from discussion with Glynn:

			* change RUN_GISBASE and RUN_GISRC to be based on ARCH_DISTDIR - this makes it possible to override them for an extension build. Then move them from platform.make.in to grass.make.in, as they are then not configured values.<br/><code>RUN_GISBASE = ${ARCH_DISTDIR}<br/>RUN_GISRC = ${RUN_GISBASE}/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}</code>
			* move LIB_PREFIX, LIB_SUFFIX and GRASS_LIBRARY_TYPE from grass.make.in to platform.make.in, as they are configured values. Though, leave the version variables, which are configured values, in grass.make.in? Why not put those in platform.make.in, and have grass.make.in -> grass.make - then there is just one configured make fragment, platform.make.in?
			* have 2 values in ARCH_INC and ARCH_LIBPATH, based on ARCH_DISTDIR and GISBASE. In a normal build, they are the same. In an extension build, ARCH_DISTDIR is the extension source "staging area" and GISBASE is the installed binary base, and thus will pick up both as needed. There appear to be a few module makefiles that use GISBASE that should be updated to use ARCH_DISTDIR.<br/><code>ARCH_INC = -I$(ARCH_DISTDIR)/include -I$(GISBASE)/include<br/>ARCH_LIBPATH = -L$(ARCH_DISTDIR)/lib -L$(GISBASE)/lib</code>
			* some main makefile stuff is needed in the fragments to enable installation in alternate (ie external to installed GRASS) locations. It was suggested to move common install features to an new makefile fragment.
			* dependencies need to be taken care of in bin and etc targets. vpath seems to be the key. And it's not critical, as nothing is actually built by dependencies.

			= GEM =

	''[...in progress... more to come...]''		''[...in progress... more to come...]''

⚠️Kyngchaos: /* Other Pages */

2007-10-20T16:57:07Z

Other Pages

← Older revision		Revision as of 16:57, 20 October 2007
Line 5:		Line 5:
	= Other Pages =		= Other Pages =

	* [[(Development) GEM}]] - Current GEM SVN setup		* [[Development GEM]] - Current GEM SVN setup
	* [[GRASS 7 ideas collection#Conceptual Changes\|GRASS 7 Conceptual Changes]] - formalizing a user GRASS prefs and addons dir		* [[GRASS 7 ideas collection#Conceptual Changes\|GRASS 7 Conceptual Changes]] - formalizing a user GRASS prefs and addons dir

⚠️Kyngchaos: New extension development ideas page

2007-10-20T16:55:35Z

New extension development ideas page

New page

= General =

Gather ideas and resources on developing extensions. Especially for installing extensions external to the main GRASS installation.

= Other Pages =

* [[(Development) GEM}]] - Current GEM SVN setup
* [[GRASS 7 ideas collection#Conceptual Changes|GRASS 7 Conceptual Changes]] - formalizing a user GRASS prefs and addons dir

= Environment variables =

Setting environment variables should be left up to the user or build startup.

Currently, there is a relatively new <code>GRASS_ADDON_ETC</code>. It is a list of paths which point directly to "etc/" directories where an external module can find any support data files or programs it needs (an example is the <code>adinit.dat</code> file needed by '''v.in.dwg'''). It is used by the libgis function G_find_etc(), and the general module '''g.findetc'''.

There is also <code>GRASS_ADDON_PATH</code>, which has been around for many years, and is a list of paths to "bin/" dirs where external modules can be found. This is appended to the shell <code>PATH</code>.

To simplify the possible need for an extension to need any of the standard dirs - bin, include, lib, etc, scripts, docs,... - I suggest a variable having paths point to the common root of those, say <code>GRASS_EXTN_DIR</code>. Then, as necessary, the appropriate subdir would be added. ie init.sh would add */bin to the shell <code>PATH</code> and */lib to <code>[DY]LD_LIBRARY_PATH</code>. This can easily support the $HOME/.grass7 dir idea in the future.

<code>GRASS_ADDON_PATH</code> should be kept for backwards compatibility, and it can still be useful for random user scripts. <code>GRASS_ADDON_ETC</code> should at least be deprecated, if not completely removed - it's a recent CVS addition and I doubt anyone has used it yet.

= Compilation =

In 6.3CVS, the Makefiles are now installed. With a little Makefile cleanup, and a few extra necessary items installled (demolocation and a couple tools), an installed GRASS can support compiling an extension without needing the full GRASS source, and without needing any extra module setup (as is needed currently by GEM-enabled modules). A standard GRASS module Makefile is all the would be needed.

''[...in progress... more to come...]''