<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">To be clear: there would be generic test names (test.c, test.cpp, test.m, test.mm) and the test implementor would just choose one of these. Since each test would be inside its own directory, this would not be a problem.<div class="">Do you still have concerns if this doesn't involve the developer having to change the .cfg file every time?</div><div class=""><br class=""></div><div class="">Sean</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 3:02 PM, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m leery of the idea of hard coding test names in the lit.cfg file. This is very different from how all other uses of lit in LLVM projects are today, and I think it would be error-prone. It would be very simple for a developer to throw in a new test, not update the lit.cfg file (because you don’t need to anywhere else) and have the test not run.<div class=""><br class=""></div><div class="">I have no objection to re-arranging the directories, but we shouldn’t require that lit.cfg list the specific test files. For example you could create subdirectories under the Inputs directory that are named to match the test case, and put the inputs for the test there. This would improve organization without making lit behave differently.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2016, at 4:35 PM, Sean Callanan via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">As promised:<div class=""><br class=""></div><div class=""><a href="https://reviews.llvm.org/D26571" class="">https://reviews.llvm.org/D26571</a></div><div class=""><br class=""></div><div class="">Sean</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2016, at 3:48 AM, Aleksei Sidorin <<a href="mailto:a.sidorin@samsung.com" class="">a.sidorin@samsung.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm OK with removing common/. It was only a suggestion.<br class=""><br class=""><br class="">08.11.2016 04:33, Sean Callanan via cfe-dev пишет:<br class=""><blockquote type="cite" class="">I like this option even more, because it allows the test's name to be entirely independent from the name of the main file.<br class="">Usually, you'll want to have the same name, but I could conceive of situations where the main file might need to be named something special.<br class="">I'd put your recommendation as my most favorite, with the caveat that I would generally discourage a "common" directory to avoid interdependencies.<br class=""><br class="">Sean<br class=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 2:06 PM, Alexey Sidorin <<a href="mailto:alexey.v.sidorin@ya.ru" class="">alexey.v.sidorin@ya.ru</a>> wrote:<br class=""><br class="">Thank you, Sean.<br class=""><br class="">There is also another option which eliminates Input:<br class=""><br class="">test-name/{main.c,other-files.c}<br class="">common/<br class=""><br class="">Example:<br class="">exprs-c/{main.c,from.c,to.c}<br class="">exprs-cxx/{main.cpp,from.cpp,to.cpp}<br class="">ctors/{main.c,from.c,to.c}<br class="">common/{stl-like-header.h,system-include.h}<br class="">etc.<br class=""><br class=""><br class="">08.11.2016 00:47, Sean Callanan via cfe-dev пишет:<br class=""><blockquote type="cite" class="">Aleksei Sidorin recently suggested that the layout of test/ASTMerge/Inputs is not very pretty, and I agree. When tests become more complicated than the traditional structure<br class=""><br class="">a.c<br class="">Inputs/a1.c<br class="">Inputs/a2.c<br class=""><br class="">then it gets harder to tell the inputs for one testcase from the inputs for another. There are a couple of solutions. I list them in order of my decreasing preference:<br class=""><br class="">- a.c-Inputs/*<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>This would eliminate the global Inputs directory altogether and have a clearly-named input directory for each individual test.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>It will make it very quick to recognize and navigate to the inputs for a test.<br class="">- Inputs/a.c/*<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>This would keep inputs in their own directory, but further sequester them into test-specific directories.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>This means you get a cleaner view of the test case files themselves, although especially for ASTMerge they're not terribly useful by themselves.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>It also means you can possibly have files in Inputs/ that are common to multiple tests. Personally I feel this can lead to bloat and interdependencies.<br class="">- The status quo, with better naming<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>This would keep a flat structure for Inputs/, with filenames sharing a prefix with their test file. With more complicated tests, or if files need to have specific names, this can be problematic.<br class=""><br class="">I'm planning to introduce a diff for this this week, and currently I'm planning to adopt the a.c-Inputs/ scheme. Please let me know if there's something I haven't considered that would argue for a different approach.<br class=""><br class="">Sean<br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></blockquote><br class=""></blockquote>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></blockquote><br class=""><br class="">-- <br class="">Best regards,<br class="">Aleksei Sidorin<br class="">Software Engineer,<br class="">IMSWL-IMCG, SRR, Samsung Electronics<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>