<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="">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><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="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<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="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<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></body></html>