www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Structuring a library =?UTF-8?B?cHJvamVjdOKAlGJlc3QgcHJhY3RpY2Vz?=

reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
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
Feb 11 2009
next sibling parent reply Zarathustra <adam.chrapkowski gmail.com> writes:
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
Feb 11 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
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
Feb 11 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Feb 12 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Feb 12, 2009 at 4:39 AM, Joel C. Salomon <joelcsalomon gmail.com> w=
rote:

 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=3Dgald
        [gald]
        [test.d]
        target=3Dtest_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?

 =97Joel 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
Feb 11 2009