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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev