Per my note about accessing user addon modules outside the GRASS application installation, such as in their home folder, I made an attempt at a function to locate a file in configured etc locations.
I'm not much of a C programmer, and really I just modified a copy of find_file.c. Tear it apart and give it to me straight 
The 3 possible etc folder locations it will look are:
1: the user's home folder
2: a globa/system folder
3: the GRASS application folder (or, the current default)
It needs a couple configured vars to set the user and global folders. I put these in in a new etc.h. The user dir is relative to HOME and the global should be an absolute dir. ie, for OSX:
#define ETC_PATH_USER "Library/GRASS/6.3/Modules/etc"
#define ETC_PATH_GLOBAL "/Library/GRASS/6.3/Modules/etc"
Existing, builtin, modules don't need to be changed to use this. It's really only necessary for external modules that have support data files. v.in.dwg would be an example, if that was built and installed outside the GRASS application (and that is probably necessary for binary distributions).
(attachments)
find_etc.c (70 Bytes)
find_etc.c (1.19 KB)
William Kyngesburye wrote:
Per my note about accessing user addon modules outside the GRASS
application installation, such as in their home folder, I made an
attempt at a function to locate a file in configured etc locations.
I'm not much of a C programmer, and really I just modified a copy of
find_file.c. Tear it apart and give it to me straight
The 3 possible etc folder locations it will look are:
1: the user's home folder
2: a globa/system folder
3: the GRASS application folder (or, the current default)
It needs a couple configured vars to set the user and global
folders. I put these in in a new etc.h. The user dir is relative to
HOME and the global should be an absolute dir. ie, for OSX:
#define ETC_PATH_USER "Library/GRASS/6.3/Modules/etc"
#define ETC_PATH_GLOBAL "/Library/GRASS/6.3/Modules/etc"
Existing, builtin, modules don't need to be changed to use this.
It's really only necessary for external modules that have support
data files. v.in.dwg would be an example, if that was built and
installed outside the GRASS application (and that is probably
necessary for binary distributions).
I don't think that what you are trying do is practical. Add-on modules
should just go into $GISBASE.
However, if you want to make a module look elsewhere for its data
files, use an environment variable rather than a compile-time setting.
--
Glynn Clements <glynn@gclements.plus.com>
On Apr 2, 2007, at 9:37 PM, Glynn Clements wrote:
I don't think that what you are trying do is practical. Add-on modules
should just go into $GISBASE.
As I suggested in a previous message to the list, putting addon modules in GISBASE is actually the impractical part.
http://grass.itc.it/pipermail/grass-dev/2007-March/029975.html
Especiallly on OSX, *adding* to an already installed application (.app package) is not recommended. And a non-admin user will simply not be able to do that.
However, if you want to make a module look elsewhere for its data
files, use an environment variable rather than a compile-time setting.
Fully controlling by the env var is probably a good idea, so it's like PATH and [DY]LD_LIBRARY_PATH. hmmm. I'd have to figure out how to split strings in C to reduce it to one env var that works like the other env vars.
Any comments on the C itself? I wasn't sure about memory allocation stuff, I'm not good with that.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
- The Ruler of the Universe
William Kyngesburye wrote:
Any comments on the C itself? I wasn't sure about memory allocation
stuff, I'm not good with that.
The main issue I see is that sprintf() doesn't return a pointer to the
buffer, so you can't you it as an argument to access().
Also, what is "if (ETC_PATH_USER)" etc supposed to be testing?
--
Glynn Clements <glynn@gclements.plus.com>
Yes, it's these sort of C details I have problems with.
On Apr 2, 2007, at 11:35 PM, Glynn Clements wrote:
William Kyngesburye wrote:
Any comments on the C itself? I wasn't sure about memory allocation
stuff, I'm not good with that.
The main issue I see is that sprintf() doesn't return a pointer to the
buffer, so you can't you it as an argument to access().
How would this be done, then?
Also, what is "if (ETC_PATH_USER)" etc supposed to be testing?
Testing whether it is not empty. I tried to use an example from elsewhere, but maybe the difference between a variable and a define makes this not usable?
Though, if I switch to using an env var, this will not be needed.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Those people who most want to rule people are, ipso-facto, those least suited to do it."
- A rule of the universe, from the HitchHiker's Guide to the Galaxy
William Kyngesburye wrote:
>> Any comments on the C itself? I wasn't sure about memory allocation
>> stuff, I'm not good with that.
>
> The main issue I see is that sprintf() doesn't return a pointer to the
> buffer, so you can't you it as an argument to access().
How would this be done, then?
sprintf(path, "%s/%s/%s", G_home(), ETC_PATH_USER, name);
if (access(path,0) == 0)
...
> Also, what is "if (ETC_PATH_USER)" etc supposed to be testing?
>
Testing whether it is not empty. I tried to use an example from
elsewhere, but maybe the difference between a variable and a define
makes this not usable?
If you want to test whether a macro is defined, you need to use
"#ifdef ..." or "#if defined(...)".
--
Glynn Clements <glynn@gclements.plus.com>