[GRASS-dev] Wingrass and TclTk

[Glynn Clements]

Brad Douglas wrote:

> > > Why not check and disable parts that do not have the required
> > > program(s)?
> > 
> > There's no need to disable a script just because the host doesn't have
> > the files it uses. The host doesn't need them and the target may well
> > have them.
> 
> I disagree only because most scripts do not exit informatively enough
> for users to discover and correct the problem.

If the user doesn't have the program, the fact that it exists on the
build system doesn't mean anything. Conversely, there's no need for
someone building GRASS to track down and install programs which aren't
required for building it (I'm missing several of the less common
programs used by the scripts, but that hasn't stopped me from building
Cygwin packages which include all of the scripts).

Also, many scripts explicitly check for any uncommon utilities which
they use. If they don't, the shell will generate a "command not found"
error for any missing program.

> > > Target<->host isn't a great argument.  You can say that with just about
> > > anything in configure. 
> > 
> > No; configure checks what is required for building a project. It
> > cannot detect whether you will be able to run it, and doesn't attempt
> > to.
> 
> True, but there's no rule against it and I've seen other projects do it.

I've seen other projects do plenty of things which I wouldn't
recommend.

> > > In the vast majority of instances, GRASS is
> > > packaged.  When I build a new RPM spec file, configure.in is very useful
> > > in revealing dependencies.
> > 
> > You shouldn't be listing every program which some script *might* use
> > as a dependency.
> > 
> > The dependencies for a GRASS RPM (etc) should be those packages
> > without which it will be largely unusable (e.g. GDAL, PROJ). It would
> > be quite annoying if you wanted to install it for use in a web
> > application and it insisted upon installing Tcl/Tk, X, OpenGL etc.
> 
> Again, I disagree.  I think you're underestimating the stupidity of
> humans.  If someone needs it for a specific application, then they
> should build it themselves.  I used to get quite a few emails until I
> significantly tightened up the dependencies.  I now get 0 other than the
> occasional query about why GRASS has so many dependencies, which is why
> I now build two versions.

It's quite common for systems with many components to be split into
multiple packages, typically a "core" package and collection of
add-ons. E.g. the gcc source is a single tar file, but distributions
often provide a separate package for each language.

If anything warrants that kind of treatment, GRASS certainly does. 
Even if you use all of the 23 different --without-* switches, you
still get most of GRASS.

> However, I have no problem so long as you're nominating yourself to deal
> with every user that reports problems that are caused by missing
> programs. ;-)  (Not terribly frequent, but frequent enough for me)
> 
> As a compromise, how about just putting that list on the wiki or in
> grass6/rpm to make it easier for packagers to build dependencies (in the
> interest of quelling some of the non-problem reports)?

I don't see any problem putting it on the Wiki, as long as it's
understood that the list will probably never be complete. New
dependencies are likely to be added as fast as people find the
existing ones.

-- 
Glynn Clements <glynn at gclements.plus.com>