Hi Eur,

Welcome to the matrix... Please first read, carefully, the wiki page
dedicated to this script. I've also given you plenty of example in my recent
posts.

There are plenty of options, that's true, but there are here for good
reasons ! First of all, it's because it's quite highly configurable. you'd
think it's too much ? Well I'm more than glad that my JALLIB_PYTHON env var
was useful for you :)


Some comment (but read them *after* you read the wiki page)

    jallib test [-u|-a|-d|-m other_matrix.yaml] [-f testing_matrix.yaml]
>                 [-s path/to/sample] [-p picname] [-n pic1,pic2,...]
>                 [-g template.tmpl [-o page.html] [-1] [-t template.tmpl]]
>
>
> too many options!
>

No, there are a



>
> Use this option to handle the testing matrix and the test result page.
>
>
> handle?
>
>     -u: update an existing testing matrix, by searching for new samples.
>         Tests must be manually added to the testing matrix file (because
>         tests are not relevant to all target chips). This won't erase
>         previous testing results, but will potentially add new sample
>         lines to the testing matrix file.
>
>
> ??? Can I just lie in my pod and supply the sentient machines with my
> bioelectricity? I don't want to know what the Matrix is!
>
>         -e: erase samples which are declared in the matrix, but don't exist
>                 anymore on the filesystem/repository. Ex: when samples are
> renamed
>                 the matrix needs to be updated (-u) to include renamed
> samples,
>                 then it needs to be pruned (-e) to remove old samples.
>
>
> erase. That can't be good.
>
>     -a: add or update a test result. If the test does not exist, it's
>         added to the matrix, else results will be updated.
>         The format is target:test_file:[EMAIL PROTECTED]
>         If pysvn module is installed, will automatically get revision
>         information for given sample. Else, you'll need to specify the
>         revision, using @revision format. Using the full format with
>         revision will also bypass getting information from SVN using
>         pysvn, even if this module is installed.
>
>         For example:
>          * to register a new test which passed, for 16f88
>             -a 16f88:new_test.jal:true
>          * to register a new test which failed, for 16f877
>             -a 16f877:new_test.jal:false
>          * to register a new test, not run yet, for 16f648a
>             -a 16f648a:new_test.jal:null
>          * to register a new test without pysvn installed (manual),
>            assuming the test is working for revision 143
>             -a 16f628:new_test.jal:[EMAIL PROTECTED]
>
>
> ????? I'm taking the blue pill here.
>
>
>     -d: delete/unregister test. The format is: target:test_file. Ex:
>         To remove a test from 16f88 device:
>             -d 16f88:bad_test.jal
>
>
> delete. Can't be good.
>
>     -m: merge another testing matrix with the main one specified with
>         option -f. All test results found in this other matrix will
>         replace those found in the main matrix. This option, with -n one,
>         allows to work on a small subset of PICs, and then re-integrate
>         the results in the main testing matrix.
>
>
> Merge the Matrix!  Better leave that to the Architect.
>
>
>     -p: print current test result for a given PIC
>
>     -n: only consider the list of PICs while generating the matrix. PICs
>         are comma separated. Ex:
>             -n 16f88,16f877,16f877a
>
>     -G: generate HTML a testing matrix from tests results, and dedicated
>         test result pages for each PIC, from both samples and tests.
>
>     -g: generate all dedicated test results page for each PIC
>
>     -1: only generate testing matrix for PIC which have at least one test
>         executed, whether passed or failed.
>
>     -t: also generate dedidated test result pages for each PIC, using given
>         template. The output file will be named as: test_<picname>.html
>         (not implemented yet)
>
>     -o: specify output HTML file. Used with -G option. If omitted, will be
>         named the same as the template file, with ".html" extension
>         If -g is also specified, then param's dirname will be used to
> produre html
>         files for each PICs.
>
>     -f: file storing the testing matrix results. YAML formatted. If not
>         specified, will look for a JALLIB_MATRIX environment variable.
>
>     -s: path to the sample directory. If no option is given, it will
> expect
>         to define as an environment variable, JALLIB_SAMPLEDIR. If no
> option
>         is given, and no env. variable can be found, the current directory
>         will be considered. The sample(s) directory(ies) *must* contain a
>         'by_device' directory.
>
>
> You've lost me here. I was under the impression that a test matrix would
> generate samples for a certain PIC from board files and test.jal files. Does
> it?
> If so, how?
>
> What about the myriad of other options?
>
>
> ---
>
> ir EE van Andel [EMAIL PROTECTED]  http://www.fiwihex.nl
>
> Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands
>
> tel+31-546-491106 fax+31-546-491107
>
>
>
> >
>


-- 
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to