[GRASS-dev] Wingrass and TclTk

[Hamish]

> > > > > > Let's just all try and put together a complete list of what's
> > > > > > needed first, then I'll have a go at it.
Brad:
> > > > > I haven't been following the thread, but caught something interesting
> > > > > in this message.
> > > > > 
> > > > > It may be overkill, but I'd like to add configure checks for the
> final
> > > > > listing.  What we have has served us well, but adding more checks
> > > > > takes little time and would help catch portability issues.
> > > > > 
> > > > > Please cc: me on the final list unless someone decides this would be
> > > > > more clutter than solution.
Glynn:
> > > > configure is meant for compile-time checks. You can still build GRASS
> > > > without the utilities which are used in scripts. Conversely, just
> > > > because the utilities are present on the host, it doesn't mean that
> > > > they will be present on the target.
> > > 
> > > 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.

Please provide an example. I am not aware of any with special deps that do not
exit with "hey! you need to install awk to use this!" or something like that.
If those checks are missing for a non-standard utility program, then the bug is
in the script and should be fixed there. But I am not aware of any.

 
> > > 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.

No rule against it doesn't mean it's a good idea. It's a mistake to assume that
3rd party programs installed on the packager's machine will be on the user's
machine too.

> > > 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.

Debian, has both "Build-depends:" and "Depends:, Suggests:, Recommends:" lines
in the control file for build time and run time deps. I would hope RPM has
something similar.


> 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)?


Yes, absolutely these programs should be listed in the REQUIREMENTS.html file.
(that is linked to on the downloads page)

FWIW, see the "Optional packages" section of the cygwin download page.


Hamish


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com