<div dir="ltr">I'm looking at ways of simplifying the lit config files. Currently, almost every lit.cfg and <a href="http://lit.site.cfg.in">lit.site.cfg.in</a> has a ton of copied code. I kind of understand why this is necessary architecturally now, so now I'm looking at how to break it apart.<div><br></div><div>For example, every single lit config file has a block of code that looks like this:</div><div><br></div><div><div><br></div><div># Check that the object root is known.</div><div>if config.test_exec_root is None:</div><div> # Otherwise, we haven't loaded the site specific configuration (the user is</div><div> # probably trying to run on a test file directly, and either the site</div><div> # configuration hasn't been created by the build system, or we are in an</div><div> # out-of-tree build situation).</div><div><br></div><div> # Check for 'lit_site_config' user parameter, and use that if available.</div><div> site_cfg = lit_config.params.get('lit_site_config', None)</div><div> if site_cfg and os.path.exists(site_cfg):</div><div> lit_config.load_config(config, site_cfg)</div><div> raise SystemExit</div><div><br></div><div> # Try to detect the situation where we are using an out-of-tree build by</div><div> # looking for 'llvm-config'.</div><div> #</div><div> # FIXME: I debated (i.e., wrote and threw away) adding logic to</div><div> # automagically generate the lit.site.cfg if we are in some kind of fresh</div><div> # build situation. This means knowing how to invoke the build system though,</div><div> # and I decided it was too much magic. We should solve this by just having</div><div> # the .cfg files generated during the configuration step.</div><div><br></div><div> llvm_config = lit.util.which('llvm-config', config.environment['PATH'])</div><div> if not llvm_config:</div><div> lit_config.fatal('No site specific configuration available!')</div><div><br></div><div> # Get the source and object roots.</div><div> llvm_src_root = lit.util.capture(['llvm-config', '--src-root']).strip()</div><div> llvm_obj_root = lit.util.capture(['llvm-config', '--obj-root']).strip()</div><div> clang_src_root = os.path.join(llvm_src_root, "tools", "clang")</div><div> clang_obj_root = os.path.join(llvm_obj_root, "tools", "clang")</div><div><br></div><div> clang_tools_extra_src_root = os.path.join(clang_src_root, "tools", "extra")</div><div> clang_tools_extra_obj_root = os.path.join(clang_obj_root, "tools", "extra")</div><div> # Validate that we got a tree which points to here, using the standard</div><div> # tools/clang layout.</div><div> this_src_root = os.path.dirname(config.test_source_root)</div><div> if os.path.realpath(clang_tools_extra_src_root) != os.path.realpath(this_src_root):</div><div> lit_config.fatal('No site specific configuration available!')</div><div><br></div><div> # Check that the site specific configuration exists.</div><div> site_cfg = os.path.join(clang_tools_extra_obj_root, 'test', 'lit.site.cfg')</div><div> if not os.path.exists(site_cfg):</div><div> lit_config.fatal(</div><div> 'No site specific configuration available! You may need to '</div><div> 'run "make test" in your Clang build directory.')</div><div><br></div><div> # Okay, that worked. Notify the user of the automagic, and reconfigure.</div><div> lit_config.note('using out-of-tree build at %r' % clang_obj_root)</div><div> lit_config.load_config(config, site_cfg)</div><div> raise SystemExit</div></div><div><br></div><div>It's obviously copy / pasted, as even the comments are the same.</div><div><br></div><div>This is not the only example either, probably 50% of lit.cfg files are copy / paste. I'm trying to eliminate all of this.</div><div><br></div><div>Again, I already kind of understand the basic idea of what needs to be done, I just want to make sure I'm testing all use cases.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 11, 2017 at 10:32 AM Matthias Braun <<a href="mailto:mbraun@apple.com">mbraun@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe tell us what you want to change?<br>
<br>
Indeed lit is used in various ways outside of llvm.<br>
<br>
libcxx and the llvm test-suite both have a bigger amount of custom python code for their lit tests and break easily when changing lit.<br>
<br>
- Matthias<br>
<br>
> On Sep 10, 2017, at 10:32 PM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> What are all the different ways people run lit? I'm doing some refactoring and want to make sure I have all the based covered. Obviously you can use check-llvm. And you can also run llvm-lit.py in your bin directory and point it to your source tree.<br>
><br>
> What else? Both of the aforementioned methods require running cmake first, is there any use case where someone runs lit without having run cmake first? Or anything else I'm not thinking of?<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div>