Re: [GRASS-dev] CLI!=GUI
make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui as far as the debian grass package goes, perhaps we could have a main grass package, which depended on grass-base and grass-gui packages. The -base package wouldn't depend on the -gui package, so folks who didn't want the GUI deps could avoid it. also apt-get install grass would still install what people expect: base+gui. not sure if -base or -core is preferred, but whichever.. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
MAKE system patches into studio! Be ready to deal also with any code that migh assume GUI-related tools to be present by default. Saving less than 10MB of uncompressed disk space is not worth a large effort. GRASS has so many dependencies, that it's impossible to split-out all tools that require some obscure lib/utility without ruining GRASS as whole. I doubt that Debian now is providing ALL dependencies of ALL GRASS modules - reports about module X requires Y will not go away because of GUI/CLI split. As GRASS lacks manpower - code or GTFO* ;) Maris. * A nice reference to Chatroulette 2010/11/30, Francesco P. Lovergine fran...@debian.org: Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Tue, Nov 30, 2010 at 4:12 AM, Glynn Clements gl...@gclements.plus.com wrote: Francesco P. Lovergine wrote: Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. You can package it how you want, but I don't think that it's realistic to structure GRASS around individual packagers' policies (e.g. who says what is core and what isn't). Well, I think that Francesco suggestion above is pretty clear. It does not look like too strange to me and sufficiently generic. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Michael Barton wrote: I'm not sure that GRASS will even run on Windows without the GUI. Certainly xdrivers will not. None of the standalone display drivers (d.mon ...) will run on Windows. d.* commands always behave as if GRASS_RENDER_IMMEDIATE=TRUE, i.e. they will save an image to $GRASS_PNGFILE. Other commands are unaffected. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sun, Nov 28, 2010 at 09:29:28PM +, Glynn Clements wrote: Hamish wrote: If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. Paolo: OK, so, now I'm complaining ;) : packagers, please have your saying here. disk space is very cheap. package maintaining time is not. IMHO unused libraries a couple extra packages do no real harm It isn't a couple. Once you link against wx, you're looking at ~60 extra libraries. I'd suggest that the core GRASS package shouldn't list X, wxWidgets or (in 6.x) Python as dependencies. It shouldn't be necessary to split the actual GRASS distribution into GUI and non-GUI components. Put everything in the non-GUI package, and have a separate GUI package which is empty (or contains a single dummy file if the packaging system doesn't allow empty packages) and exists solely to hold the GUI-specific dependencies. As said in another mail of mine, it is not a problem brute-splitting GUI dependencies (e.g. current squeeze release for 6.4 only *suggests* wxpython dependencies). Moving GUI-related binaries in different packages is a pain to maintain, but theoretically it can also be done. It remains a brute hack anyway, which is a symptom of a fundamental design problem: the whole system is theoretically layered and modular, but in fact it cannot be really componentized in a *clean* way. Something I find basically disturbing and not elegant, sorry my purism. BTW, I tend to disagree about considering GUI maintainance not influent in the releasing cycle. It *is* influent and caused many of the past/present windows/macos delays. Having a sort of grass-toolbox and grass-gui sub-projects could help a lot (like CNES does with OTB and Monteverdi). And like it or not, there are people that do not use the default GUI or a GUI at all. Splitting would gain consensus about the core, which is IMVHO the true value of GRASS. Of course, my 2 cents, as always. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Francesco P. Lovergine wrote: As said in another mail of mine, it is not a problem brute-splitting GUI dependencies (e.g. current squeeze release for 6.4 only *suggests* wxpython dependencies). Moving GUI-related binaries in different packages is a pain to maintain, but theoretically it can also be done. It remains a brute hack anyway, which is a symptom of a fundamental design problem: the whole system is theoretically layered and modular, but in fact it cannot be really componentized in a *clean* way. Something I find basically disturbing and not elegant, sorry my purism. You are really going to have to explain what you are talking about, otherwise I (and possibly others) are going to conclude that you don't have a clue and should just be ignored. GRASS' structure is about as layered and modular as you can get. If you install it on a system without GUI libraries, the only portions which won't work are those which inherently cannot function without those libraries (i.e. the GUI, digitiser, XDRIVER). And like it or not, there are people that do not use the default GUI or a GUI at all. Like me. The only time I'll run the GUI is if I need to test some aspect of the GUI. Which is why I have no idea where you're getting these notions about integration from. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Mon, Nov 29, 2010 at 10:20:52PM +, Glynn Clements wrote: Francesco P. Lovergine wrote: As said in another mail of mine, it is not a problem brute-splitting GUI dependencies (e.g. current squeeze release for 6.4 only *suggests* wxpython dependencies). Moving GUI-related binaries in different packages is a pain to maintain, but theoretically it can also be done. It remains a brute hack anyway, which is a symptom of a fundamental design problem: the whole system is theoretically layered and modular, but in fact it cannot be really componentized in a *clean* way. Something I find basically disturbing and not elegant, sorry my purism. You are really going to have to explain what you are talking about, otherwise I (and possibly others) are going to conclude that you don't have a clue and should just be ignored. GRASS' structure is about as layered and modular as you can get. If you install it on a system without GUI libraries, the only portions which won't work are those which inherently cannot function without those libraries (i.e. the GUI, digitiser, XDRIVER). Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Nov 29, 2010, at 5:28 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Tue, 30 Nov 2010 00:26:20 +0100 From: Francesco P. Lovergine fran...@debian.org Subject: Re: [GRASS-dev] CLI!=GUI To: Glynn Clements gl...@gclements.plus.com Cc: Francesco P. Lovergine fran...@debian.org, grass-dev@lists.osgeo.org Message-ID: 20101129232620.ga6...@frankie.is-a-geek.org Content-Type: text/plain; charset=us-ascii On Mon, Nov 29, 2010 at 10:20:52PM +, Glynn Clements wrote: Francesco P. Lovergine wrote: As said in another mail of mine, it is not a problem brute-splitting GUI dependencies (e.g. current squeeze release for 6.4 only *suggests* wxpython dependencies). Moving GUI-related binaries in different packages is a pain to maintain, but theoretically it can also be done. It remains a brute hack anyway, which is a symptom of a fundamental design problem: the whole system is theoretically layered and modular, but in fact it cannot be really componentized in a *clean* way. Something I find basically disturbing and not elegant, sorry my purism. You are really going to have to explain what you are talking about, otherwise I (and possibly others) are going to conclude that you don't have a clue and should just be ignored. GRASS' structure is about as layered and modular as you can get. If you install it on a system without GUI libraries, the only portions which won't work are those which inherently cannot function without those libraries (i.e. the GUI, digitiser, XDRIVER). Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. This may work for folks on Linux but is incompatible with the way software is installed and used on Mac and Windows. I'm not sure that GRASS will even run on Windows without the GUI. Certainly xdrivers will not. Michael -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Francesco P. Lovergine wrote: Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. You can package it how you want, but I don't think that it's realistic to structure GRASS around individual packagers' policies (e.g. who says what is core and what isn't). Every optional dependency can be disabled at configure time. At build time, you can build individual directories. In 7.0, you can control the target directory (ARCH_DISTDIR) separately from the directory where previously built components are found (GISBASE). Packaging involves work, and GRASS is no different to any other package. E.g. most modern Linux distributions split libraries between a run-time package containing the shared libraries and a -devel package containing the headers, static libraries etc. The source tree from which the package is built doesn't provide explicit support for this; it's just something the packager has to do. Moreover, integrating (and subsequently maintaining) the support for various packaging systems would be significantly more work for the GRASS developers than it would take for the package maintainers to maintain their own packaging systems privately. A privately-maintained system only needs to work to the level of works for me. Something intended for inclusion into the source tree has to be more finished, which can take more work than creating the original version. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Glynn ha scritto: If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. Paolo: OK, so, now I'm complaining ;) : packagers, please have your saying here. disk space is very cheap. package maintaining time is not. IMHO unused libraries a couple extra packages do no real harm where it does matter (embedded systems) the user will probably want to custom build from source anyway. I do not much like the idea of making the packaging scripts any more complicated than absolutely needed. I do not much like the idea of e.g. the grass debian package merely recommending the GUI be installed as well, even if it is technically possible not to require it. The rationale is: decoupling CLI and GUI will make the release cycle smoother I humbly suggest that in practice it will only complicate things and add unneeded burden to the release manager(s). From a code point of view they are decoupled already. best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Hamish wrote: If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. Paolo: OK, so, now I'm complaining ;) : packagers, please have your saying here. disk space is very cheap. package maintaining time is not. IMHO unused libraries a couple extra packages do no real harm It isn't a couple. Once you link against wx, you're looking at ~60 extra libraries. I'd suggest that the core GRASS package shouldn't list X, wxWidgets or (in 6.x) Python as dependencies. It shouldn't be necessary to split the actual GRASS distribution into GUI and non-GUI components. Put everything in the non-GUI package, and have a separate GUI package which is empty (or contains a single dummy file if the packaging system doesn't allow empty packages) and exists solely to hold the GUI-specific dependencies. [FWIW: I once tried SuSE Linux. It kept wanting to install a good chunk of KDE because what were essentially command-line tools had been built with optional (and mostly trivial) GUI features enabled. I lasted around three days before ditching it for Gentoo.] -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Hi, 2010/11/27 Markus Neteler nete...@osgeo.org: On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini cavall...@faunalia.it wrote: E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? Likely not, but --without-wxwidgets should help. it will just disable wxGUI digitizer (wxNviz has been rewritten to python). We could add new flag --without-gui which would disable compiling (and installing selected components). martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sat, Nov 27, 2010 at 11:43:02AM +0100, Martin Landa wrote: Hi, 2010/11/27 Markus Neteler nete...@osgeo.org: On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini cavall...@faunalia.it wrote: E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? Likely not, but --without-wxwidgets should help. it will just disable wxGUI digitizer (wxNviz has been rewritten to python). We could add new flag --without-gui which would disable compiling (and installing selected components). martin That would be the very first step, indeed. Of course IMHO a full solution would imply also: - having a componentized GUI which could be added to the core without rebuilding the whole beast (possibly componentizing 2d/3d would be also a good idea). - decoupling gui/core releases: my impression is that the core could evolve much fastly than the gui. That's based on counting the current number of GUI related bugs in comparison with core ones. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
for the record I regularly build grass 6.5svn on an old debian/etch machine which has no wx2.8 avail. ie just for the CLI. It copies python files into a gui/ dir at install but never uses them. C++ wx modules are not build (cleanly). no problems at all... zero. as per dual packages, I'd say not necessary, extra work for very little gain. it would just save a megabyte or two on the install. the gui development is very good at exposing limitations in the CLI versions of everything, so it's natural that they both grow together. and it is already very well separated at the code level. the only thing that aren't are interactive apps which are not relevant to the CLI-only crowd. 2c, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 27/11/2010 23:40, Hamish ha scritto: for the record I regularly build grass 6.5svn on an old debian/etch machine which has no wx2.8 avail. ie just for the CLI. It copies python files into a gui/ dir at install but never uses them. C++ wx modules are not build (cleanly). no problems at all... zero. please think of normal users: believe it or not, people does not compile their packages, and rely on executables. as per dual packages, I'd say not necessary, extra work for very little gain. it would just save a megabyte or two on the install. this is not the point: it will save unnecessary dependencies. That's why in sane OSs packages are split in several independent subpackages. the gui development is very good at exposing limitations in the CLI versions of everything, so it's natural that they both grow together. and it is already very well separated at the code level. the only thing that aren't are interactive apps which are not relevant to the CLI-only crowd. if they are well separated, why not separating them, giving more freedom to users? I agree that GUI and CLI will grow together, but why waiting in the release of one part just because the other is still to be fixed? The rationale is: decoupling CLI and GUI will make the release cycle smoother, and allows a greater freedom, especially for 3rd party applications, either desktop or web. I would like to see GRASS spreading further in the freeGIS arena, and I'm suggesting this could be a way. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Paolo Cavallini wrote: Like Martin said, because GRASS is modular, anyone can compile it or use it with or without the GUI. I use it heavily with the GUI for some things. For others, I use it completely scripted, without any GUI, and called from a completely different environment. This kind of flexibility is a real value for this piece of software. AFAIK this is not true: compiling (better: packaging - believe it or not, not *anyone* is capable of compiling) without the GUI requires changes in the source code. Such as? Sorry to insist, I realize my position is not popular among GRASS devs, but there is a number of situations where having a pure CLI package would bring great advantages. E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? If you don't want to install wxWidgets, don't install it. The only part of GRASS which requires it is the GUI. The rest of GRASS will work fine without it. If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. The only binaries (executables and libraries) which have a dependency upon a GUI library are those which simply cannot function without one: NVIZ, xganim, the OGSF library, etc. [This isn't necessarily true in 7.0; if you build --with-cairo and cairo has X support enabled, then the display library will have X as a direct dependency.] -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 28/11/2010 02:51, Glynn Clements ha scritto: If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. OK, so, now I'm complaining ;) : packagers, please have your saying here. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 21/11/2010 21:36, Michael Barton ha scritto: Like Martin said, because GRASS is modular, anyone can compile it or use it with or without the GUI. I use it heavily with the GUI for some things. For others, I use it completely scripted, without any GUI, and called from a completely different environment. This kind of flexibility is a real value for this piece of software. AFAIK this is not true: compiling (better: packaging - believe it or not, not *anyone* is capable of compiling) without the GUI requires changes in the source code. Sorry to insist, I realize my position is not popular among GRASS devs, but there is a number of situations where having a pure CLI package would bring great advantages. E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? Please, help us poor users: separate the two packages, and we'll all be happier. I do not think it's a major work, and packagers can probably give a hand. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 21/11/2010 21:36, Michael Barton ha scritto: Like Martin said, because GRASS is modular, anyone can compile it or use it with or without the GUI. I use it heavily with the GUI for some things. For others, I use it completely scripted, without any GUI, and called from a completely different environment. This kind of flexibility is a real value for this piece of software. AFAIK this is not true: compiling (better: packaging - believe it or not, not *anyone* is capable of compiling) without the GUI requires changes in the source code. Sorry to insist, I realize my position is not popular among GRASS devs, It is moreover a question how many work is involved... but there is a number of situations where having a pure CLI package would bring great advantages. I compile GRASS myself quite often as CLI package. E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? Likely not, but --without-wxwidgets should help. Please, help us poor users: separate the two packages, and we'll all be happier. I do not think it's a major work, and packagers can probably give a hand. A concrete work estimate would be desired. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 21/11/2010 21:36, Michael Barton ha scritto: There is nothing inherently wrong with releasing different parts of GRASS at different times.But trying to manage a single release cycle for GRASS has been pretty complicated and my hat is off to Markus. Trying to manage multiple release cycles would be more complicated. My suggestion is that decoupling CLI and GUI will make the release cycle simpler, not more complicated. We do not need additional complexity. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote: Hi, 2010/11/20 Paolo Cavallini cavall...@faunalia.it: I know it's an old thread, and that not everybody agrees, but I still think, after talking with people more knowledgeable than me, that separating the core of GRASS (libraries+CLI) from the GUI(s) will make the release and packaging process faster and smoother, and the integration with other software, both desktop and web, easier and cleaner. Can we revive the discussion about this? well, my option is very subjective - wxGUI is going to be a solid GUI for GRASS. Anyone can build it's own GRASS distribution without any GUI (libraries and subset of the GRASS modules). But it's not task for the core GRASS developers. They are creating solid environment --- GRASS libraries + modules (CLI) and also the GUI. Feel free to take what you what from this composition. Martin What Paolo is probably trying (also?) to say is that GUIs and core could have completely different release cycles. The GUI should be a component like any other, to be released when ready, but that should not become a permanent blocker of the release process, like did happen in the 6.4 release. Many people (like me and many other) use Grass as a scripting language and are completely uninterested in having a stable GUI at all, but are interested in having a working stable core in reasonable times. Of course, IMHO applies. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Hi, 2010/11/20 Paolo Cavallini cavall...@faunalia.it: I know it's an old thread, and that not everybody agrees, but I still think, after talking with people more knowledgeable than me, that separating the core of GRASS (libraries+CLI) from the GUI(s) will make the release and packaging process faster and smoother, and the integration with other software, both desktop and web, easier and cleaner. Can we revive the discussion about this? well, my option is very subjective - wxGUI is going to be a solid GUI for GRASS. Anyone can build it's own GRASS distribution without any GUI (libraries and subset of the GRASS modules). But it's not task for the core GRASS developers. They are creating solid environment --- GRASS libraries + modules (CLI) and also the GUI. Feel free to take what you what from this composition. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
