[GRASS5] OOP and 3rd party libs

[John Huddleston]

To libe or not to libe that is the question, whether tis nobler...

Really, the question is not whether to include or certain libraries
for our use; rather, how can we make GRASS extensible so that
it remains a viable alternative for GIS work.

Two examples of current systems that allow installation of modules
for extending the capability of the system are perl and cygwin.
Perl has a directory system that is checked before the addition
of any module.  They have three primary files for configuration.
In analogy to grass, it would be something like this:

/usr/local/grass-5.0b/Math/gsl

and in that directory would be have gsl.a, extralibs.all, extralibs.ld,
gsl.dll ( or gsl.so for solaris and/or gsl.sl for hpux)

The Cygwin toolset used to be a monolithic install procedure.  Good
control but difficult to change and hard to add modules (programs).
When they merged with Redhat, they changed the install procedure
so that a setup.exe program can install one (or all) program from
the web or from the local drive.  It's much better way to allow users
to add programs to the system.

Given these two examples, given the fact that we want GRASS to
succeed, let's look down the road on how to make it so users can
download a module of their choosing (Python,gsl,Octave,etc.)
and incorporate those features into an application that serves
their needs.  Grass will surely survive if we provide this capability.

John Huddleston


----- Original Message -----
From: David D Gray <ddgray at armadce.demon.co.uk>
To: Grass Developer List <grass5 at geog.uni-hannover.de>
Sent: Tuesday, June 06, 2000 9:17 AM
Subject: [GRASS5] OOP and 3rd party libs


> Hi developers
>
> I have been giving some thought recently to the question of third
> party libraries in the GRASS environment, and how far we
> might want to go in incorporating them into the main
> distribution. To give a few of the matters arising:
>
> 1. Most large scale projects in the number-crunching zone,
> whether they are free software, open source, public domain,
> or whatever, incorporate some form of the BLAS/LAPACK libraries
> for efficient linear algebra computations. Am I right in thinking
> GRASS does not have this? Its presence would take a lot of
> the burden away from developing separate routines in each module
> and allow developers to concentrate on GIS specific code.
>
> 2. As an extension to the above there is the whole question of
> linking to Fortran code. We already have some Fortran routines.
> Do we have any Fortran developers? If I am right, this was
> settled in the GRASS camp about 10 years ago - long before my time -
> when it was decided as policy that future development would
> concentrate on C and Fortran routines would be deprecated.
> This is fine as far as it goed but I don't think we should
> reject external Fortran routines if they do a specific job
> more efficiently,  and in any case will be maintained by others
> who have skills more appropriate to the task, eg. mathematicians.
> I am thinking of things where heavy repetitive number-crunching is
> involved - co-ordiantes transformations, as in projection support,
> possibly, finite element analysis, stats or (as above) linear algebra
> routines.
>
> 3. Extending further, what about useful libs in other languages.
> There is a lot of code in C++, and some in Ada95, that might be
> useful. Again even if we are not using these languages ourselves
> they are widely cross-platform and easy to link to C code. It is
> much easier to find implementations of B-trees, RSTrees and the like
> in C++ than in C, and they are often well-maintained.
>
> 4. Then - how much do we want ot rely on third party libraries?
> They will generally be maintained by others, though they will
> be GPL/BSD licensed, so we should be able to modify/improve them
> as we see fit, and return the results to the broader community.
>
> 5. Finally, what about OOP. DO we want to start developing OOP
> rouitnes within GRASS itself. I know some people regard OOP as
> unnecessary, but others might feel the edge it gives development
> to be indispensable. Others don't like C++. But there are
> other options: Ada95 I have mentioned, and we have already
> had numerous postings where people have praised Python as a
> worhty development language for GRASS (with which I concur). There
> is also Objective-C, which is more like a `natural' extension to
> C itself, but is perhaps not so portable right now.
>
> I would be interested to know if anyone else has had any
> thoughts on these matters, and if so what they see as the
> way forward.
>
>
> Best wishes
>
>
> David
>
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write
to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'