<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 15, 2022 at 7:34 PM <a href="mailto:stes@PANDORA.BE">stes@PANDORA.BE</a> <<a href="mailto:stes@telenet.be">stes@telenet.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<a href="http://docs.openindiana.org/dev/userland/" rel="noreferrer" target="_blank">http://docs.openindiana.org/dev/userland/</a><br>
<br>
requires an update to first define "test" as a TARGET<br>
<br>
because test is not listed in the table after <br>
<br>
"To build a component you simply cd into the directory of the software, and type "gmake TARGET" (here we use gmake to call GNU make), where TARGET can be one of:"<br>
<br>
some targets are listed but "test" is not one of them.<br>
<br>
Further down there is just one paragraph as documentation about the whole process:<br> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
"It's advised to put the expected test ouput in test/results-BITS.master (where BITS are either 32 or 64) and to ensure that the gmake test target generates reproducible results. You can use the COMPONENT_TEST_TRANSFORMS variable to set a list of sed directives to transform the test output and make it reproducible."<br>
<br>
This is not entirely correct as BITS can also be "all" instead of 32 or 64.<br>
<br>
Also from your reply I understand that there are 2 usages:<br>
<br>
1) run "gmake test" to run a set of tests<br>
2) run "gmake test" to run a test-and-compare if test/results-BITS.master already exists<br>
<br>
So basically "gmake sample-test" something like that could create an empty tests/results-BITS.master,<br>
just like "sample-manifest" is creating a sample manifest.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">The maintainer's guide that I had started writing on the wiki did not make it to the docs website (yet):</div></div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><a href="https://oi-wiki-test.madgwick.xyz/35913833.html">https://oi-wiki-test.madgwick.xyz/35913833.html</a></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><a href="https://oi-wiki-test.madgwick.xyz/2.-Overview-of-the-Build-System_37060624.html">https://oi-wiki-test.madgwick.xyz/2.-Overview-of-the-Build-System_37060624.html</a></div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><a href="https://oi-wiki-test.madgwick.xyz/3.-Common-Tasks_37060626.html">https://oi-wiki-test.madgwick.xyz/3.-Common-Tasks_37060626.html</a></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">The last page contains information on transforms.<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
----- Op 14 okt 2022 om 1:53 schreef Tim Mooney via oi-dev <a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a>:<br>
<br>
> In regard to: [oi-dev] COMPONENT_TEST_TRANSFORMS for PARI, stes@PANDORA.BE...:<br>
> <br>
>> Because PARI/gp is using its own Configure do I have to define<br>
>> COMPONENT_TEST_TRANSFORMS to remove all compile/build output ??<br>
> <br>
> Probably. Whenever I wanted to have comparable test results for<br>
> a component, I found it easiest to use a filter to delete everything<br>
> up to the start of the tests, and then additional filters to remove<br>
> anything that would be system-specific or variable within the tests<br>
> (e.g. timing for test runs, dates and times, system name, etc.).<br>
> <br>
>> I am not sure the documentation on oi-userland build is sufficient<br>
>> regarding to "gmake test".<br>
> <br>
> Especially for someone just starting out, the current documentation<br>
> alone is probably not enough. You're not a beginner, but even you<br>
> have run into questions.<br>
> <br>
> When I was starting out, I got good help from Alexander, Michal, Aurelien,<br>
> etc. Most of the time the help was pointing me at an existing example in<br>
> a different component, that did something similar to what I needed to do<br>
> for the component I was stuck on.<br>
> <br>
> What might be useful is for you to inventory the components that have<br>
> test output for comparison (under various possible names), and then check<br>
> the Makefile for these to find what COMPONENT_TEST_TRANSFORMS are in<br>
> place. That should give you a lot of examples to start with. I know that<br>
> for the perl components I worked on and any libraries, I tried to<br>
> make certain there was a comparison file for the test suite.<br>
> <br>
>> Any suggestions ?<br>
> <br>
> If I was updating a component that didn't have a test comparison file yet,<br>
> I would start by creating an empty one, via something like<br>
> <br>
> touch test/results-all.master<br>
> <br>
> (or a BITS-specific variant or alternate output name).<br>
> <br>
> I would generally then start running the test suite, tweaking the<br>
> COMPONENT_TEST_TRANSFORMS to filter out more of the output, and manually<br>
> updating the starting comparison file. Frequently this involved saving<br>
> "diff" output and adding it to the comparison file while stripping the<br>
> diff markers like "+" at the beginning of a line and line-number markers.<br>
> <br>
> As long as you're familiar with the "diff" format, it's pretty easy, and<br>
> if you have a bunch of components to update the repetition will get you<br>
> to the point where you're very comfortable with the process.<br>
> <br>
> Tim<br>
> --<br>
> Tim Mooney <a href="mailto:Tim.Mooney@ndsu.edu" target="_blank">Tim.Mooney@ndsu.edu</a><br>
> Enterprise Computing & Infrastructure /<br>
> Division of Information Technology / 701-231-1076 (Voice)<br>
> North Dakota State University, Fargo, ND 58105-5164<br>
> <br>
> _______________________________________________<br>
> oi-dev mailing list<br>
> <a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
> <a href="https://openindiana.org/mailman/listinfo/oi-dev" rel="noreferrer" target="_blank">https://openindiana.org/mailman/listinfo/oi-dev</a><br>
<br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="https://openindiana.org/mailman/listinfo/oi-dev" rel="noreferrer" target="_blank">https://openindiana.org/mailman/listinfo/oi-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font style="font-family:courier new,monospace" size="1">---<br>Praise the Caffeine embeddings<br></font></div></div></div></div></div>