<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
On Jul 21, 2021, at 5:26 PM, Damian Rouson <<a href="mailto:rouson@lbl.gov" class="">rouson@lbl.gov</a>> wrote:<br class="">
<div>
<blockquote type="cite" class=""><br class="Apple-interchange-newline">
<div class="">
<div style="caret-color: rgb(0, 0, 0); font-family: TrebuchetMS; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
For testing, I was originally planning to use the<span class="gmail-Apple-converted-space"> </span><a href="https://gitlab.com/everythingfunctional/vegetables" class="">Vegetables</a><span class="gmail-Apple-converted-space"> </span>unit testing framework,
which I like because it supports writing tests in the form of a specification. I would also like to add a capability for building the tests using the Fortran Package Manager (<a href="https://github.com/fortran-lang/fpm" class="">fpm</a>). Doing so is trivial
-- much simpler than modifying the CMake and with the benefit that it's trivial to set things up so that fpm automatically downloads any test dependencies such as Vegetables and we don't have to touch the CMake scripts. Alternatively, if this proves problematic
in any way, I'll commit a simple assertion utility borrowed from the<span class="Apple-converted-space"> </span><a href="https://github.com/sourceryinstitute/sourcery" class="">Sourcery</a><span class="Apple-converted-space"> </span>library.</div>
</div>
</blockquote>
<br class="">
</div>
<div>Hi Damian, </div>
<div><br class="">
</div>
<div>Just a quick note to give you a feel for the testing infrastructure here — it is much broader than what it might appear at first glance as you have to look beyond Flang. </div>
<div><br class="">
</div>
<div>The testing mechanisms need to be usable/stable across the community as testing and releases are done LLVM-wide (across all projects: Clang, MLIR, Flang, LLVM, etc.). As a result, any new external package dependencies could have an impact across established
mechanisms across all projects (e.g., see <a href="https://lab.llvm.org/buildbot" class="">https://lab.llvm.org/buildbot</a> for a glance at coverage, platforms, etc.). </div>
<div><br class="">
</div>
<div>For this reason, I would suggest adopting existing capabilities from the current mechanisms used across the LLVM infrastructure as your starting point. A key step will be to make sure any approach taken can be run without additional requirements on the
broader community — or we will have to open a discussion with the broader community about expanding the supported infrastructure. Like everything, there are always pros and cons, but keeping Flang's approach usable and sound as a component of the larger code
base is paramount to maintaining LLVM's established testing and release process. </div>
<div><br class="">
</div>
<div>Thanks, </div>
<div><br class="">
</div>
<div>—Pat</div>
<div><br class="">
</div>
</body>
</html>