Brad Douglas wrote: > > > > Let's just all try and put together a complete list of what's > > > > needed first, then I'll have a go at it. > > > > > > 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. > > > > 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. > 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. > 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. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
