Welcome to the Jungerl!

[Joakim G.]

Kent Boortz wrote:

>Sean Hinde <Sean.Hinde@REDACTED> writes:
>  
>
>>I do think this will need some active management from someone who gets a
>>kick out of organising things (i.e. defintely not me!) To be useful for the
>>widest audience we really need to avoid it becoming Junkerl.. Like should we
>>have a new project called
>>random_build_tools_which_are_all_useful_but_dont_work_together?! I guess the
>>project mailing list is the place to sort these issues out.
>>    
>>
>
>Maybe to much work but I think the best way to maintain code like this
>is to include some sort of automatic testing similar to what we do
>with OTP. Create a cron job on some test machines that
>
>  Update the local CVS tree from the CVS repository at sourceforge.
>
>  Build from the sources. This is the most basic test ;-)
>
>  Run some tests for each contribution. Even trivial tests like to
>  start and stop an application is better than nothing. Maybe using
>  the test server. The test server may look complicated at first but
>  once you have got it running it is really easy to add new tests to
>  it. The test result will be HTML pages that can be made public. The
>  result page for each test links to the test source for that test so
>  in a way the tests are also examples of how to use the contributed
>  code.
>  
>

I have  a test suite  for the  xmlrpc package (I will add it as well) 
and to start
it I just:

$ cd lib/xmlrpc/test
$ make
<run all tests producing stdout noise and either suceed or fails>

Dead simple. Going for the test server for jungerl is overkill IMO.

I propose that we go for the dead simple approach when it comes to 
build/test
requirements on each lib as well.

Mandatory files/directories:
lib/App/ebin/
lib/App/include/
lib/App/Makefile

Optional files/directories:
lib/App/test/Makefile (optional?)
lib/App/priv (optional)
lib/App/doc (optional)

Cheers
/Jocke