Am Samstag, 19. März 2016 um 23:12:32, schrieb Guenter Milde
<mi...@users.sf.net>
> On 2016-03-19, Kornel Benko wrote:
> > Am, 19. März 2016 um 10:15:35, schrieb Guenter Milde <mi...@users.sf.net>
> >> On 2016-03-18, Kornel Benko wrote:
>
> Dear Kornel,
>
> thanks for the response. Some loose bits...
>
>
> >> > No non-alpha characters in a label (like dash, so no '-')
>
> >> Is this a ctest restriction, a limitation in your test scripts or a
> >> convention?
>
> > For me it is convention. It make _my_ life easier not to have special
> > chars with special handling. For instance we use '#' for comments, so
> > labels should not be part of a label.
>
> OK
>
> >> Does the underline '_' work? ...
>
> > Not checked, but most probably it would work.
>
> Fine.
>
> ...
>
>
>
> >> ... currently we cannot have "unreliable:texissue" because
> >> "texissue" is also used in "suspiciousTests" ("inverted:texissue").
>
> > Have you tried? I didn't see any such restriction in the code.
> > I tried and it works.
>
> I tried once and just tried again and got:
>
> -- Reading list suspiciousTests
> -- Reading list ignoredTests
> -- Reading list suspendedTests
> -- Reading list unreliableTests
> -- Label "texissues" already in use. Reused in unreliableTests
>
> but maybe this is just a warning?
>
Yes, warning only. Ignore if intended.
> >> Alternative suggestion for Sublabel line parsing:
>
> >> Instead of replacing not allowed characters with "_", we could also
> >> just ignore anything after the first "word" (sequence of characters that
> >> are considered valid in a label).
>
> > This is done now. Anything that is considered as not valid label char
> > is treated as a separator.
>
> The difference is that currently "words" following the separator
> are also turned into labels.
This is the intended behaviour.
> Therefore, we need to clarify whether this should be independent labels
> (of same depth) or sublabel + subsublabel ...
>
> Alternatives are
> a) join them (e.g. with "_")
OK
> b) ignore everything after the first separator
I wanted the possibility to have more than one label specified.
> > Since you want to discard 'but no error', you could also simply write
> > "Sublabel: wrong_output # but no error"
> > or
> > "Sublabel: wrong # output"
> > without need to change the code.
>
> This was just an example. Actually, I don't see the need to specify more
> than one sublabel in a line.
I did not want to disable this case.
> I do want a parsing algorithm that is simple and easy to explain with a
> way to specify labels that consist of more than one word (like
> "wrong_output") and a simple rule for handling lines with "separator"
> characters.
>
>
OK
> ...
>
>
> >> -L and -LE cannot be combined!
>
> >> (at least currently, maybe this is due to
> >> your use of just one label per test case?)
>
> > Are you sure? I was not aware of this.
> > For instance trying 'ctest -L texissue -LE examples -N' works here.
>
> You are right. (I remember problems when exploring the selection options some
> times ago but cannot reproduce this now.)
>
>
>
>
> >> >> 2. Labels for the "location" are not really required:
>
> >> >> E.g. `ctest -N -R "_export/mathmacros/"` can be used to uniquely
> >> >> select all "mathmacro" tests.
>
>
> >> The question is which part of "test properties" are selected via label
> >> and which via name. This should be decided on real use cases under the goal
> >> to keep the system simple.
>
> > Via name the labels are all uppercase.
>
> I know. But I still suggest that labels for "mathmacros", "examples",
> "templates", "manuals" are not required and without them the test system
> would become easier to understand and use.
OK
> ...
>
...
Kornel
signature.asc
Description: This is a digitally signed message part.
