<div dir="ltr">android, bs2000, djgpp, wince, ios, uefi, mpe, vos, uclinux, vxworks - i.e. at least 26+ platform definitions are in the category of "make test" does not work (in general)<div>and that isn't talking about the other platforms where it might work or might now which I doubt anyone has compiled on for a least a decade </div><div><br></div><div>The *majority* of the platforms are in unknown status - by definition - according to our platform policy - and a significant portion of the platforms defined do not support successful execution of "make test".<br><div><br></div><div>Tim.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 8:34 AM, Salz, Rich <span dir="ltr"><<a href="mailto:rsalz@akamai.com" target="_blank">rsalz@akamai.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">UEFI is one such exception<br>
<div class="HOEnZb"><div class="h5"><br>
On 1/10/18, 5:07 PM, "Richard Levitte" <<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>> wrote:<br>
<br>
I'd say that for the "big" platforms, we do require full build and<br>
full test to say that "it works". I would say that should be the base<br>
criteria we work with.<br>
<br>
But then, I can see reasons to make exceptions from these criteria.<br>
As you say, on some platforms, only the libraries are built. I can<br>
also imagine a situation where we cross compile everything, and perl<br>
isn't available on the target architecture, which makes our tests<br>
impossible. These should be noted for sure if we decide to support<br>
them, but *as exceptions* to the base criteria.<br>
<br>
In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-<wbr>9=<a href="mailto:gX0nLreARdES_bSeNcow@mail.gmail.com">gX0nLreARdES_bSeNcow@mail.<wbr>gmail.com</a>> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <<a href="mailto:tjh@cryptsoft.com">tjh@cryptsoft.com</a>> said:<br>
<br>
tjh> Follow on from the discussion in PR#5035, I think we need to add a "status" definition to the<br>
tjh> platform which should cover the different contexts:<br>
tjh><br>
tjh> 1) libraries compile<br>
tjh> 2) apps compile<br>
tjh> 3) make test passes<br>
tjh><br>
tjh> We have platforms where we don't compile the apps and we have platforms where there are<br>
tjh> issues in the tests - i.e. the library (with or without the apps) compiles and operates correctly but<br>
tjh> there is a defect in the tests.<br>
tjh> Defects in tests or defects in the apps are different to defects in the libraries.<br>
tjh> The apps not being ported also does not mean the platform is unusable.<br>
tjh><br>
tjh> That level of differences should be recorded. Perhaps a status for each?<br>
tjh><br>
tjh> - libcrypto<br>
tjh> - libssl<br>
tjh> - apps<br>
tjh> - tests<br>
tjh><br>
tjh> For many platforms, the apps and the tests simply don't work or are not used; and our test<br>
tjh> automation platform also does not operate for many platforms.<br>
tjh><br>
tjh> Tim.<br>
tjh><br>
tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <<a href="mailto:kaduk@mit.edu">kaduk@mit.edu</a>> wrote:<br>
tjh><br>
tjh> On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:<br>
tjh> > Speaking of platforms, I think we need to discuss what we actually<br>
tjh> > include in the secondary category. The platform policy currently<br>
tjh> > mentions these:<br>
tjh> ><br>
tjh> > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS<br>
tjh> ><br>
tjh> > For Windows and VMS, I know for sure that it follows our definition of<br>
tjh> > the secondary category (*), but for FreeBSD and MacOS X, I think we<br>
tjh> > may have lost the people who actively supported them (for FreeBSD,<br>
tjh> > that was Ben Laurie as far as I recall).<br>
tjh> ><br>
tjh> > So I think we need a raise of hands, here and now:<br>
tjh> ><br>
tjh> > 1. Is there anyone currently present on this list that want to take<br>
tjh> > on FreeBSD or MacOS X?<br>
tjh><br>
tjh> I guess maybe this is overcome by events since I commented on github<br>
tjh> already, but I can take FreeBSD (amd64). I can spin up i386 FreeBSD<br>
tjh> in the lead up to new releases but don't normally use it on a<br>
tjh> regular basis.<br>
tjh><br>
tjh> -Ben<br>
tjh> ______________________________<wbr>_________________<br>
tjh> openssl-project mailing list<br>
tjh> <a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
tjh> <a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
tjh><br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
</div></div></blockquote></div><br></div>