Hi,
> Author: hamish
> Date: 2011-12-04 16:05:50 -0800 (Sun, 04 Dec 2011)
> New Revision: 49533
>
> Modified:
>
> grass/branches/develbranch_6/gui/scripts/g.extension.py
> Log:
> avoid unnecessary build clutter in private installs
> (see #1501, sync with r49527);
> only create build dirs for option=add
Martin:
I *really* don't understand why all (almost all) the files
needs to be moved around by `g.extension`.
here are the sum total of the grass6 addons installation:
mv bin/* .
mv scripts/* .
rmdir bin/ scripts/
mv man/ docs/
-- and that's it --
This is not some massive re-ordering, this is making
g.extension be a tidy citizen and finish its install, as it
should have been from the start.
Let's keep in GRASS6 things as they are
g.extension is a new module which so far remains ~unfinished.
6.4.2 will be the first release where it actually works for
everyone. this is our last chance to fix it before what we
decide gets locked in for the rest of the 6.x lineage.
ignoring the problem now will only make things worse.
Your changes make `g.extension` in G6 more and more
complicated, less readable, please keep the things
simple.
as above, this is basically 3 "mv" commands to finish the
install. hardly a huge amount of complication or complex
interaction.
worst case is 3 lines of string substitution to accommodate that.
If you want to go with install manifest files or whatever, I'm
happy to do write those lines of code for you too as it's not
hard and I'm willing to support it.
I can't see anything good when over-complicated `g.extension`
tries to "fix" standard installation made by building system.
For the n-th time, GRASS_ADDON_PATH is not GISBASE*. It was never
meant to be GISBASE. There is no reason for it to be exactly
matching GISBASE.
For 9 years GRASS_ADDON_PATH has been a component of the $PATH.
In the last year or so it has been hijacked to be used as
--prefix= instead. I should have nipped that in the bud when it
first happened, but to my regret I didn't.
[*] if you want to rename it GRASS_ADDON_BASE in grass7 and use
it like a fake GISBASE, I don't mind that at all, have fun.
and anyway, better to have an intelligent g.extension and a
clean user experience than a dumb g.extension and cluttered
user experience. it is one thing that Apple has figured out
since long ago: make the developers do the hard work so that
the user doesn't have to.
It's tricky, just waste of time, keep to decide building
system where is target of the files.
the shell script version has it right I think, the build system
builds the module in .tmp/, for system wide installs to GISBASE
it installs using 'make install', for installs to GRASS_ADDON_PATH
it copies the files in manually. there is really nothing highly
complicated or tricky about it.
again, the changes boil down to:
mv bin/* .
mv scripts/* .
mv man/ docs/
not exactly redefining the API, and any other module extra files
built into there remain in their natural spots.
Modify build system directly, don't try to hack `g.extension`
to get what you want. GRASS7 is a playground not GRASS6.
I find that to be a bit of a strawman argument, I would not
think for a moment to change the grass6 build system to make
g.extension 'easier'. Very much the opposite! the build system
is fine. the problem is attempting to use 'make install' when
it is not appropriate to do so.
I am asking you to revert all the recent changes in
`g.extension` (BASH and Python) and keep in GRASS6 things
as defined by building system.
Then we can discuss how to change building system
in GRASS7 to satisfy all the needs.
For the n-th + 1 time, GRASS_ADDON_PATH is not GISBASE.
The build system has nothing to do with it.
currently what is in devbr6 works, is clean, and does not
redefine/hijack GRASS_ADDON_PATH late in the stable release
series. I will not apologize for working code.
here is a sample of what 6.5svn gives you now:
$ ls addons/
d.barb* docs/ g.md5sum* i.points.auto* r.fuzzy* r.surf.volcano*
... and now that it's working you want to mess it up again? why?
for what technical gain? it works solidly now (afaik) and is nice
and clean, let's just enjoy it. If you want help with the
wingrass manifest stuff just ask, I'm happy to help.
aside:
it is a big mistake to think that the addon path only exists
for g.extension, and so can be a hidden mess of directories
which are centrally managed by software.
often it will mainly be user-managed for personal scripts.
things like two little text+execute scripts for switching back
and forth between default databases or little shortcuts like
'x0' for selecting or starting a monitor. I've got dozens of
these things before I even get to my reusable job scripts.
Personally, I am confused from `g.extension` in G6,
and I'm confused in the middle of the wxGUI code, but that's
ok and doesn't mean there is anything wrong with it, just ask..
it's starting to more and more complicated,
creating our own multi-platform CRAN-like system was never
going to be simple. but I don't forsee too many additional
changes will be needed, and am not at all temped to refactor
known working code.
tries to "fix" building system,
No, it builds naively using the build system into .tmp/; uses
the main build system for system-wide installs to GISBASE; and
for private installs to $HOME manually copies the files to where
they need to go. the build system is never molested, just used
where it is appropriate to be used, and not where it isn't.
RC3 requested by you.
it is many times better for the software and for developer-
relations 
that we sort this out now, before release.
x1000
Only one acceptable "hack" for me is creating the symlink/copy
for exe/bat files ($GRASS_ADDON_PATH/bin -> $GRASS_ADDON_PATH)
nothing more.
a) moving executables into the real $PATH dir is not a hack.
moving the manuals into the documentation folder is not a hack.
-duplicate files, folders, and symlinks is a huge messy hack,
which doesn't have to be; it's already solved; why unsolve it?-
b) may I ask why you care where the man pages go in a private
install? or why bin/ and scripts/ must be kept separate when
nothing in the codebase cares? I'd much rather have g.extension
install to addons properly than hack the main init.sh to try to
accommodate the mess of two extra & superfluous ADDON_PATHs,
and leave the user with a needlessly cluttered home dir.
in summary-
what's in devbr6 is stable and working fine AFAIK. I asked for
testing and comments a number of times before committing with
no response. I'll ask again as I'm genuinely interested to learn
of any technical problems:
"with an empty (or non-existent) addons dir could you try [...] grass 6.5's g.extension [...] and installing a few addon modules? After seeing it I hope you agree it is a much cleaner way to organize things. If there is a technical reason not to clean that up I'd still like to hear what it is, as I know of none."
regards,
Hamish
Only one file which is