I’m starting work on my Geometric Algebra library <http://www.dsource.org/projects/gald>, and I’d like some tips on structuring the source tree. Is there a “standard” place to put the library test/demonstration?

Right now I’m starting with:

trunk/
      gald/
           e2.d
      test.d
      dsss.conf

with the files as follows:

e2.d:
	module gald.e2;

	struct vector2 {
		real x;
		real y;
	}

test.d:
	module test;

	import gald.e2;

	int main(char[][] args) {
		vector2 v;
		return 0;
	}

dsss.conf:
	name=gald
	[gald]
	[test.d]
	target=test_gald

Is this a reasonable start, or am I buying trouble for myself with the layout and module declarations? What are the “best practices” for such a project?

—Joel Salomon

Hello Joel

Maybe, you should look on the Helix Library.
www.dsource.org/projects/helix
But in my opinion you should write down all classes which You want to implement in your library, and then all relations between these classes. This approach warrants you essentially correct structure. I don't know what do you mean when you write "test". If you want to test yours classes then the best method are the unittests. But if you only want to verify that library was correct installed then you just should use any component of the library. That as you do that in your example code. If you will write more about targets of your library then I could tell you more.
I really apologizefor my horrible English, but I hope you understood.

------------------------------------

Joel C. Salomon Wrote:

> I’m starting work on my Geometric Algebra library <http://www.dsource.org/projects/gald>, and I’d like some tips on structuring the source tree. Is there a “standard” place to put the library test/demonstration?
> 
> Right now I’m starting with:
> 
> trunk/
>       gald/
>            e2.d
>       test.d
>       dsss.conf
> 
> with the files as follows:
> 
> e2.d:
> 	module gald.e2;
> 
> 	struct vector2 {
> 		real x;
> 		real y;
> 	}
> 
> test.d:
> 	module test;
> 
> 	import gald.e2;
> 
> 	int main(char[][] args) {
> 		vector2 v;
> 		return 0;
> 	}
> 
> dsss.conf:
> 	name=gald
> 	[gald]
> 	[test.d]
> 	target=test_gald
> 
> Is this a reasonable start, or am I buying trouble for myself with the
> layout and module declarations? What are the “best practices” for such a
> project?
> 
> —Joel Salomon

On Thu, Feb 12, 2009 at 4:39 AM, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> I'm starting work on my Geometric Algebra library <http://www.dsource.org/projects/gald>, and I'd like some tips on structuring the source tree. Is there a "standard" place to put the library test/demonstration?
>
> Right now I'm starting with:
>
> trunk/
>      gald/
>           e2.d
>      test.d
>      dsss.conf
>
> with the files as follows:
>
> e2.d:
>        module gald.e2;
>
>        struct vector2 {
>                real x;
>                real y;
>        }
>
> test.d:
>        module test;
>
>        import gald.e2;
>
>        int main(char[][] args) {
>                vector2 v;
>                return 0;
>        }
>
> dsss.conf:
>        name=gald
>        [gald]
>        [test.d]
>        target=test_gald
>
> Is this a reasonable start, or am I buying trouble for myself with the layout and module declarations? What are the "best practices" for such a project?
>
> —Joel Salomon
>

That looks ok to me.  You might end up with more tests, so you might want to put test.d  in a "tests" or "gald_tests" subdir instead at the top level.

--bb

On Thu, Feb 12, 2009 at 6:02 AM, Zarathustra <adam.chrapkowski@gmail.com> wrote:
> Hello Joel
>
> Maybe, you should look on the Helix Library. www.dsource.org/projects/helix

Well, I wouldn't recommend you copy their idea of having a single
top-level template that encloses all your types[1].  AFAIK, that
doesn't have any benefit over making each type templated individually,
and makes creating aliases for specific types more cumbersome, i.e.
their:
   alias LinearAlgebra!(float).Vector2 Vector2f;
vs just:
   alias Vector2!(float) Vector2f;

I think probably also forces instantiation of the entire template any time you use any part of it, which means some unnecessary code bloat.

If you do want to do such grouping for some reason, it's probably easier to go the other way and make things as individual types first, then make the group template with all the component types as aliases.

Like
template LinearAlgebra(FloatT) {
   alias Vector2!(FloatT) Vector2;
   alias Vector3!(FloatT) Vector3;
   ... etc
}

--bb [1]http://www.dsource.org/projects/openmeshd/browser/trunk/Helix/helix/linalgebra.d

Zarathustra:
>If you want to test yours classes then the best method are the unittests. But if you only want to verify that library was correct installed then you just should use any component of the library.<

I think that it's better to put unit tests as close as possible to the things they test, so after each damned function/template/class/thinghie you can put an unittest that tests all the corner cases you can dream of.
Then in a separate place, like a directory with tests, you can put higher level tests, that test functionality, etc.

Bye,
bearophile