[GRASS-dev] gmath/gpde Patch for grass6.5 and grass7

GRASS GRASS developer
1

Dear devs,
i have created a patch for grass6.5 and grass7 which modifies the gmath and gpde libraries and
introduce parts of the ccmath library into grass to get rid of the numerical recipes code in the gmah library.

The following changes are done:

1.) I have moved the linear equation solver code from gpde lib to gmath lib
2.) I have implemented blas level 1, 2 and 3 algorithm in gmath lib
3.) I have modified the gmath solver to use the grass blas implementation
4.) I have implemented a wrapper for ATLAS blas level 1 algorithms
5.) I have updated the gpde library tests
6.) I have implemented gmath library tests for the numerical part
7.) I have modified the groundwater flow modules to use the gmath solver
8.) I have added a new library to grass called ccmath (LGPL license) to replace the NR algorithms of the gmath library in the future

The CCMATH is a mathematics library, coded in C, that contains functions for linear algebra,
numerical integration, geometry and trigonometry, curve fitting, roots and optimization,
Fourier analysis, simulation generation, statistics, special functions, sorts and searches,
time series models, complex arithmetic, and high precision computations. [ostatic.com]

I have extracted the gmath relevant algorithms out of the ccmath library (linear algebra and eigenvalue analyses)
and modified the grass ccmath.h to define only the extracted algorithms. The ccmath library will be included by the gmath.h file only.
All ccmath functionality will be wrapped by the gmath library (work in progress).

The ccmath library in grass is located in lib/ccmath.

The integration of the library was the first step.
The next steps which should be done (by me) are:
1.) Creating a wrapper around the ccmath library to use the grass copy or an extern ccmath lib within grass via the gmath lib.
2.) Replacing the NR code with the ccmath version (via gmath wrapper).
3.) Implementing tests for the ccmath lib.
4.) Replacing redundant numerical code in grass modules with the gmath implementations

To enable the usage of extern versions of the ccmath or ATLAS library, the configure procedure need to be modified.
I have no clue how to do this, but i will try if somebody can point me in the right direction. :slight_smile:

The patches and a list of changed, removed and added files are available here:
grass6.5:
http://www-pool.math.tu-berlin.de/~soeren/grass/files/patch_gpde_gmath_ccmath_grass6_devel_2009_08_11.diff
http://www-pool.math.tu-berlin.de/~soeren/grass/files/patch_gpde_gmath_ccmath_grass6_devel_2009_08_11_file_status.txt

grass7:
http://www-pool.math.tu-berlin.de/~soeren/grass/files/patch_gpde_gmath_ccmath_grass7_2009_08_11.diff
http://www-pool.math.tu-berlin.de/~soeren/grass/files/patch_gpde_gmath_ccmath_grass7_2009_08_11_file_status.txt

The patches are based on the latest svn versions of grass7 and grass6.5.

In case the developers don’t have any objections against the patch, i would like to see them commited to the svn repositories.
Because i do not have write permissions on the osgeo grass reporitory, a developer with write acces must do this please.

To verify my changes in grass and to check for broken dependencies, i have updated the GRASS Test Suite for grass65.
The test suite is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite_0.2.0.14.tar.bz2

The test results, inclusively the gpde and gmath tests are available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.4/

Any questions are welcome,
best regards
Soeren

2

Soeren wrote:

In case the developers don't have any objections
against the patch, i would like to see them commited to the
svn repositories.
Because i do not have write permissions on the osgeo grass
reporitory, a developer with write acces must do this
please.

since you were already accepted as a developer and had CVS write access
on the old server, all you need to do now to activate SVN write access on
the new server is post to the grass-psc mailing list giving your osgeo ID
and that you have read+understand+accept the RFC2 document.

see https://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheMainGRASS-SVNrepository

cheers,
Hamish

3

Hello Hamish,

2009/8/13 Hamish <hamish_b@yahoo.com>

Soeren wrote:

In case the developers don’t have any objections
against the patch, i would like to see them commited to the
svn repositories.
Because i do not have write permissions on the osgeo grass
reporitory, a developer with write acces must do this
please.

since you were already accepted as a developer and had CVS write access
on the old server, all you need to do now to activate SVN write access on
the new server is post to the grass-psc mailing list giving your osgeo ID
and that you have read+understand+accept the RFC2 document.

see https://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheMainGRASS-SVNrepository

thanks for the hint.
I will “activate” my SVN access right now and will submit the patches in the near future,
if there are no objections against the changes and the new LGPL’d ccmath library?

best regards
Soeren

cheers,
Hamish

4

Soeren wrote:

if there are no objections against the changes and the new
LGPL'd ccmath library?

I have no comment either way on the technical side of the library changes
beyond wondering if it will peacefully interact with the (mostly unused)
existing --with-blas --with-lapack ./configure switches.

As for including a dependent library in GRASS I personally don't have
a problem with that as it does not seem to be widely available or have
much infrastructure of its own (beyond a e.g. Freshmeat.net writeup
page*). i.e. not a fork because there isn't really any new version to
keep in sync with, and users would have a hard time finding a package
for it.

As for including LGPL code in the main trunk I personally don't have a
problem with that as it reflects the upstream license/author's wishes,
is new code, and is used as a library. By my reading the RFC2 doc nor
'g.version -c' & the COPYING file need any adjustment to cover this.
But a formal decision on that may be a matter for the PSC.

As long as everything in the lib/ccmath/ dir falls under the same (GPL
compatible) license and the LGPL.txt file is placed in that dir I'd be
happy.

Hamish

[*] a web search for ccmath found a most interesting auto-georegistration
tool for applying/projecting a 3D registration onto 2D photographs:
gipfel. Check out the .avi demo.
  http://io.debian.net/~tar/debian/gipfel/
Note the track overlay is from a x,y,z text file, very neat.
reminds me a bit of i.points.auto, Stereo[1], and autopano-sift[2]
software.
[1] http://grass.osgeo.org/gdp/stereo-grass/index.html
[2] http://user.cs.tu-berlin.de/~nowozin/autopano-sift/

5

Hamish wrote:

As for including LGPL code in the main trunk I personally don't have a
problem with that as it reflects the upstream license/author's wishes,
is new code, and is used as a library. By my reading the RFC2 doc nor
'g.version -c' & the COPYING file need any adjustment to cover this.
But a formal decision on that may be a matter for the PSC.

As long as everything in the lib/ccmath/ dir falls under the same (GPL
compatible) license and the LGPL.txt file is placed in that dir I'd be
happy.

If it's being included in the main GRASS tree, it would be simpler to
relicense it as GPL.

The main thing is to ensure that each file has a header stating that
it is licensed under the LGPL. In the absence of such a header, we
can't reasonably assume that any additions to the code are licensed
under the LGPL.

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

6

2009/8/14 Hamish <hamish_b@yahoo.com>

Soeren wrote:

if there are no objections against the changes and the new
LGPL’d ccmath library?

I have no comment either way on the technical side of the library changes
beyond wondering if it will peacefully interact with the (mostly unused)
existing --with-blas --with-lapack ./configure switches.

The changes do not break or interfer the --with-blas --with-lapack ./configure switches.
The la.c file contains lapack matrix and vector functionality as well as an LU solver and
a eigenvalue vector sorter. Function names start with G_matrix or G_vector.
The ccmath wrapper as well as the numerical functions taken from the gpde libary and
the blass functionality starting with G_math.
The ccmath matrix computation functions are compatible with the default grass matrix allocation methods.

As for including a dependent library in GRASS I personally don’t have
a problem with that as it does not seem to be widely available or have
much infrastructure of its own (beyond a e.g. Freshmeat.net writeup
page*). i.e. not a fork because there isn’t really any new version to
keep in sync with, and users would have a hard time finding a package
for it.

Indeed, the last code changes are from 2001.

As for including LGPL code in the main trunk I personally don’t have a
problem with that as it reflects the upstream license/author’s wishes,
is new code, and is used as a library. By my reading the RFC2 doc nor
‘g.version -c’ & the COPYING file need any adjustment to cover this.
But a formal decision on that may be a matter for the PSC.

I will start a PSC request.

As long as everything in the lib/ccmath/ dir falls under the same (GPL
compatible) license and the LGPL.txt file is placed in that dir I’d be
happy.

I will make sure that every ccmath file includes a lgpl header and i will provide a copy of the lgpl.license file in lib/ccmath.

Best regards
Soeren

Hamish

[*] a web search for ccmath found a most interesting auto-georegistration
tool for applying/projecting a 3D registration onto 2D photographs:
gipfel. Check out the .avi demo.
http://io.debian.net/~tar/debian/gipfel/
Note the track overlay is from a x,y,z text file, very neat.
reminds me a bit of i.points.auto, Stereo[1], and autopano-sift[2]
software.
[1] http://grass.osgeo.org/gdp/stereo-grass/index.html
[2] http://user.cs.tu-berlin.de/~nowozin/autopano-sift/

7

Hello Glynn,

2009/8/15 Glynn Clements <glynn@gclements.plus.com>

Hamish wrote:

As for including LGPL code in the main trunk I personally don’t have a
problem with that as it reflects the upstream license/author’s wishes,
is new code, and is used as a library. By my reading the RFC2 doc nor
‘g.version -c’ & the COPYING file need any adjustment to cover this.
But a formal decision on that may be a matter for the PSC.

As long as everything in the lib/ccmath/ dir falls under the same (GPL
compatible) license and the LGPL.txt file is placed in that dir I’d be
happy.

If it’s being included in the main GRASS tree, it would be simpler to
relicense it as GPL.

So we have to convince the author Daniel A. Atkinson
to relicense the ccmath library as GPL code?
The only email address i have found is: DanAtk@aol.com.
I personally prefer to keep the LGPL license for ccmath.

The main thing is to ensure that each file has a header stating that
it is licensed under the LGPL. In the absence of such a header, we
can’t reasonably assume that any additions to the code are licensed
under the LGPL.

I will ensure this.

Best regards
Soeren

–
Glynn Clements <glynn@gclements.plus.com>

8

Soeren Gebbert wrote:

> If it's being included in the main GRASS tree, it would be simpler to
> relicense it as GPL.

So we have to convince the author Daniel A. Atkinson
to relicense the ccmath library as GPL code?

The LGPL explicitly permits relicensing to GPL:

  3. You may opt to apply the terms of the ordinary GNU
  General Public License instead of this License to a given
  copy of the Library. <snip>

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

9

Hello Glynn,
thanks for your suggestions. More below …

2009/8/18 Glynn Clements <glynn@gclements.plus.com>

Soeren Gebbert wrote:

If it’s being included in the main GRASS tree, it would be simpler to
relicense it as GPL.

So we have to convince the author Daniel A. Atkinson
to relicense the ccmath library as GPL code?

The LGPL explicitly permits relicensing to GPL:

  1. You may opt to apply the terms of the ordinary GNU
    General Public License instead of this License to a given
    copy of the Library.

I do not understand. What to do now?
Will we keeping the LGPL??

I don’t particularly mind, but I do think that we need to be careful
about contributions.

Ok, i fully agree.

When the overall project is licensed under the GPL, it’s reasonable to
assume that any contributions are also licensed under the GPL. If
someone contributes changes to a file which happens to be LGPL, they
might have actually intended to license their contribution under the
LGPL, or they might have just overlooked that the file in question is
LGPL. Also, it means that you can’t copy or move code from another
part of GRASS into that library.

1.) I can extend the SUBMISSION file to explain that any new numerical or mathematical code belongs into the grass gmath or gpde libraries. The ccmath lib is connected to grass via a wrapper in the gmath lib. Only the wrapper (a single C file) includes the ccmath header. The gmath header only knows the wrapper functions. So nobody should include the ccmath header directly besides the wrapper.

2.) We can make a guideline that only bug-fixing is allowed in the ccmath library (README.txt in ccmath dir). The grass ccmath part must be compatible with the 2.2.1 version of ccmath to enable external linking. IMHO i in the near future nobody will contribute to the ccmath part in grass, because the code is hardly readable and not easy to maintain.

3.) I can place an ATTENTION.txt file in the ccmath library folder, which explains the licensing issue.

If this is ok, i would like to submit my changes to svn.

Best regards
Soeren

–

Glynn Clements <glynn@gclements.plus.com>

10

Paul:

I think in this instance Hamish suggested it might be a PSC matter
because of the licensing issue

right.

Paul:

[...] the simple solution is to re-licence the LGPL code as GPL
when it goes into GRASS, to keep everything under the same licence

Soeren:

IMHO it may be difficult to re-license the ccmath library under
the GPL ... .

why? Term 3 of the LGPL exists to describe exactly how to do that.

Glynn:

When the overall project is licensed under the GPL, it's
reasonable to assume that any contributions are also licensed
under the GPL. If someone contributes changes to a file which
happens to be LGPL, they might have actually intended to license
their contribution under the LGPL, or they might have just
overlooked that the file in question is LGPL. Also, it means
that you can't copy or move code from another part of GRASS into
that library.

Soeren:

1.) I can extend the SUBMISSION file to explain that any
new numerical or mathematical code belongs into the grass
gmath or gpde libraries. The ccmath lib is connected to
grass via a wrapper in the gmath lib. Only the wrapper (a
single C file) includes the ccmath header. The gmath header
only knows the wrapper functions. So nobody should include
the ccmath header directly besides the wrapper.

2.) We can make a guideline that only bug-fixing is allowed
in the ccmath library (README.txt in ccmath dir). The grass
ccmath part must be compatible with the 2.2.1 version of
ccmath to enable external linking. IMHO i in the near future
nobody will contribute to the ccmath part in
grass, because the code is hardly readable and not easy to
maintain.

3.) I can place an ATTENTION.txt file in the ccmath library
folder, which explains the licensing issue.

If this is ok, i would like to submit my changes to svn.

Q: is the ccmath library copied verbatim or is it changed to use
gis.h, G_fatal_error() etc? ie is it cloned intact as a convenience
or has it become assimilated into grass code to the point where it
will not run on its own without libgis?

by the way, I notice that we already ship the bwidget LGPL library
  trunk/lib/external/bwidget/

That is for Tcl which is redundant for grass 7, but you can see in
there what was done wrt LGPL.txt and READMEs.

Keeping it in lib/external/ is a very good idea IMO, see also the
lib/external/shapelib/README and swig/python/NumPtr/README.GRASS
for example of comments about local changes.

also, lib/external/shapelib code has:
* Copyright (c) 1999, 2001, Frank Warmerdam
*
* This software is available under the following "MIT Style" license,
* or at the option of the licensee under the LGPL (see LICENSE.LGPL). This
* option is discussed in more detail in shapelib.html.

(ISTR Frank also posted some time ago to grass5-dev a blanket license for
GRASS to use his gdal/ogr/etc code as needed)

Certainly arbitrary mixing of licenses within general source tree
would be a mistake. But I think the lib/external/ designation makes the
situation clear enough to the programmer who might happen upon the code.

Also note that 'g.version -c' says:

"""
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.

Parts of GRASS are not copyright by the GRASS development team.
The original authors hold the copyrights and you have to abide
to their licensing terms where noted.
(Keep in mind that code linking into GRASS can only be distributed
if compatible with the GPL.)
"""

Iff the library is intact and has not been extensively modified for
GRASS, my vote would be to add it to lib/external/ (with README.grass
and LGPL.txt files), in the tradition of those other two libraries.

If the library has been reworked to be a grass library my vote would
be to use Term 3 of the LGPL and relicense it to GPL to avoid confusion.

regards,
Hamish

11

Hello Hamish,

2009/8/21 Hamish <hamish_b@yahoo.com>

Paul:

I think in this instance Hamish suggested it might be a PSC matter
because of the licensing issue

right.

Paul:

[…] the simple solution is to re-licence the LGPL code as GPL
when it goes into GRASS, to keep everything under the same licence

Soeren:

IMHO it may be difficult to re-license the ccmath library under
the GPL … .

why? Term 3 of the LGPL exists to describe exactly how to do that.

I am not concerned about the technical way, but about agreement of the original author of ccmath. Maybe i am wrong, but AFAICT as the copyright holder he has to agree that we can change the license of his code.

Glynn:

When the overall project is licensed under the GPL, it’s
reasonable to assume that any contributions are also licensed
under the GPL. If someone contributes changes to a file which
happens to be LGPL, they might have actually intended to license
their contribution under the LGPL, or they might have just
overlooked that the file in question is LGPL. Also, it means
that you can’t copy or move code from another part of GRASS into
that library.

Soeren:

1.) I can extend the SUBMISSION file to explain that any
new numerical or mathematical code belongs into the grass
gmath or gpde libraries. The ccmath lib is connected to
grass via a wrapper in the gmath lib. Only the wrapper (a
single C file) includes the ccmath header. The gmath header
only knows the wrapper functions. So nobody should include
the ccmath header directly besides the wrapper.

2.) We can make a guideline that only bug-fixing is allowed
in the ccmath library (README.txt in ccmath dir). The grass
ccmath part must be compatible with the 2.2.1 version of
ccmath to enable external linking. IMHO i in the near future
nobody will contribute to the ccmath part in
grass, because the code is hardly readable and not easy to
maintain.

3.) I can place an ATTENTION.txt file in the ccmath library
folder, which explains the licensing issue.

If this is ok, i would like to submit my changes to svn.

Q: is the ccmath library copied verbatim or is it changed to use
gis.h, G_fatal_error() etc? ie is it cloned intact as a convenience
or has it become assimilated into grass code to the point where it
will not run on its own without libgis?

Parts of the ccmath library have been copied to grass. These parts are exact clones.
No changes are made in the ccmath code.
It can run on its own without any dependencies to grass.

by the way, I notice that we already ship the bwidget LGPL library
trunk/lib/external/bwidget/

That is for Tcl which is redundant for grass 7, but you can see in
there what was done wrt LGPL.txt and READMEs.

Keeping it in lib/external/ is a very good idea IMO, see also the
lib/external/shapelib/README and swig/python/NumPtr/README.GRASS
for example of comments about local changes.

also, lib/external/shapelib code has:

  • Copyright (c) 1999, 2001, Frank Warmerdam
  • This software is available under the following “MIT Style” license,
  • or at the option of the licensee under the LGPL (see LICENSE.LGPL). This
  • option is discussed in more detail in shapelib.html.

(ISTR Frank also posted some time ago to grass5-dev a blanket license for
GRASS to use his gdal/ogr/etc code as needed)

Certainly arbitrary mixing of licenses within general source tree
would be a mistake. But I think the lib/external/ designation makes the
situation clear enough to the programmer who might happen upon the code.

Also note that ‘g.version -c’ says:

“”"
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.

Parts of GRASS are not copyright by the GRASS development team.
The original authors hold the copyrights and you have to abide
to their licensing terms where noted.
(Keep in mind that code linking into GRASS can only be distributed
if compatible with the GPL.)
“”"

Iff the library is intact and has not been extensively modified for
GRASS, my vote would be to add it to lib/external/ (with README.grass
and LGPL.txt files), in the tradition of those other two libraries.

To put the ccmath library into lib/external is a good idea. I vote for it.

If the library has been reworked to be a grass library my vote would
be to use Term 3 of the LGPL and relicense it to GPL to avoid confusion.

Best regards
Soeren

regards,
Hamish

12

Hamish wrote:

by the way, I notice that we already ship the bwidget LGPL library
  trunk/lib/external/bwidget/

That is for Tcl which is redundant for grass 7,

actually that's used by tcl NVIZ so still in use. wx NVIZ is not yet
to the point where it can replace the tcl version.
(btw, we should rename visualization/nviz2/ to be wxNViz or something;
the tcl version is already version 2.2)

I added a new lib/external/README.license file to explain things.
AFAICT the SUBMITTING file and RFCs do not require adjustment.

Hamish

13

Soeren:

> IMHO it may be difficult to re-license the ccmath library under
> the GPL ... .

Hamish:

why? Term 3 of the LGPL exists to describe exactly how to do that.

Soeren:

I am not concerned about the technical way, but about
agreement of the original author of ccmath. Maybe i am
wrong, but AFAICT as the copyright holder he has to agree
that we can change the license of his code.

The authors already gave consent to do that when they released the
code under the terms of the LGPL, which explicitly allows that.
The terms you see laid out in their LPGL.txt file are /their/ terms,
not the FSF's.

As a matter of good will it could be nice to drop them a note to thank
them and say what we have done, but I don't think we need their permission
to do it.

None the less, my 2c vote would be to keep it as LGPL and put it in the
existing lib/external/ directory.

Hamish

14

Soeren Gebbert wrote:

3.) I can place an ATTENTION.txt file in the ccmath library folder, which
explains the licensing issue.

You can't assume that someone modifying the file will have viewed the
contents of the folder. When I open a source file, it's often from
grep or compilation output (C-x ` or selecting a specific line of
output), or via M-. (find-tag, i.e. locate the point in the source
where a given symbol is defined).

If you want to ensure that the information is seen by anyone modifying
the file, the information needs to go into the file itself.

What would be better still would be if subversion could restrict the
ability to modify those files, or at least send a reminder email if
the files are modified.

An alternative would be to put the library in e.g. lib/nonGPL/ccmath
so that the pathname serves as a reminder.

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

15

Hello Hamish,
i am sorry for the delay, i was very busy in the last days …

2009/8/21 Hamish <hamish_b@yahoo.com>

Hamish wrote:

by the way, I notice that we already ship the bwidget LGPL library
trunk/lib/external/bwidget/

That is for Tcl which is redundant for grass 7,

actually that’s used by tcl NVIZ so still in use. wx NVIZ is not yet
to the point where it can replace the tcl version.
(btw, we should rename visualization/nviz2/ to be wxNViz or something;
the tcl version is already version 2.2)

I added a new lib/external/README.license file to explain things.
AFAICT the SUBMITTING file and RFCs do not require adjustment.

Ok, i will put ccmath into lib/external together with the lgpl.license file and a README.
Additionally i need to modify the lib/Makefile to put the directory external before the gmath library. But i think that is not a problem.

Best regards
Soeren

Hamish

16

Hello Glynn,
i am sorry for the delay, the last days were very stressing for me …

2009/8/21 Glynn Clements <glynn@gclements.plus.com>

Soeren Gebbert wrote:

3.) I can place an ATTENTION.txt file in the ccmath library folder, which
explains the licensing issue.

You can’t assume that someone modifying the file will have viewed the
contents of the folder. When I open a source file, it’s often from
grep or compilation output (C-x ` or selecting a specific line of
output), or via M-. (find-tag, i.e. locate the point in the source
where a given symbol is defined).

If you want to ensure that the information is seen by anyone modifying
the file, the information needs to go into the file itself.

What would be better still would be if subversion could restrict the
ability to modify those files, or at least send a reminder email if
the files are modified.

Can we modify the svn access to lib/external?
As Hamish suggested i would like to place the ccmath library into this directory,
because other LGPL libraries are located there.

Best regards
Soeren

An alternative would be to put the library in e.g. lib/nonGPL/ccmath
so that the pathname serves as a reminder.

–

Glynn Clements <glynn@gclements.plus.com>

17

Soeren Gebbert wrote:

Additionally i need to modify the lib/Makefile to put the directory external
before the gmath library. But i think that is not a problem.

It should be okay to put the external subdirectory first, as it
shouldn't depend upon anything in GRASS.

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

18

Hamish wrote:

I added a new lib/external/README.license file to explain
things.

AFAICT the SUBMITTING file and RFCs do not require adjustment.

Soeren:

Ok, i will put ccmath into lib/external together with the
lgpl.license file and a README.

actually there is nothing about the GPL or the implications
of it in the SUBMITTING file, probably it is a good idea to
add something there after all, with a "be aware that files
in lib/external/ ..." rider.

I don't think technical SVN restrictions are workable, but I'm
open to being proved wrong by a good idea.

Hamish

19

Dear developers,
i have submitted the changes to the grass6 development branch (a patch for grass7 is in development).
I have tested the patch several times and hope to not break anything in grass … .

You can test the patched grass version with the latest grass testsuite. It ships additional tests
for the ccmath, gmath and gpde libraries.
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite_0.2.0.14.tar.bz2

To compile the gmath and gpde libraries tests you have to switch to the library test directory and type make.
Doing so the modules test.gmath.lib and test.gpde.lib are available to test the libraries.
The gmath library test also ships some benchmarks for solver and blas 2,3 functions.

The next step will be the replacement of the lib/gmath/lu.c code with the ccmath version
including the patch of several modules.
And the rewrite of several modules which are using
self made matrix/vector functionality with the gmath vector and matrix functions.

regards
Soeren

2009/8/28 Hamish <hamish_b@yahoo.com>

Hamish wrote:

I added a new lib/external/README.license file to explain
things.

AFAICT the SUBMITTING file and RFCs do not require adjustment.

Soeren:

Ok, i will put ccmath into lib/external together with the
lgpl.license file and a README.

actually there is nothing about the GPL or the implications
of it in the SUBMITTING file, probably it is a good idea to
add something there after all, with a “be aware that files
in lib/external/ …” rider.

I don’t think technical SVN restrictions are workable, but I’m
open to being proved wrong by a good idea.

Hamish

20

Hi,

I get two errors compiling 6.5svn.

The first is because lib/gmath G_math_solvps() fails to return anything
when it should return int.

I think I fixed it with r38939, but please check to see if that is correct.
  https://trac.osgeo.org/grass/changeset/38939

The second is in lib/external/ccmath, eigen() is used but not declared.
I suppose it needs to be added to lib/external/ccmath/ccmath_grass.h, ??

This can be caught if you add -Werror-implicit-function-declaration to
your CFLAGS.

cheers,
Hamish