<div dir="ltr"><div>There's no way to avoid doing a transfer out of the options dictionary at some level, because it's not a straight transfer.  There's a ton of post-processing that gets done on the options dictionary in order to convert the raw options into a useful format.</div><div><br></div><div>That might be solvable with more advanced use of argparse.  This approach does get rid of one level of option transfer though.  Because we would transfer</div><div>1. From the class returned by argparse into the global</div><div>2. From the global into the lldb module</div><div><br></div><div>Now we only transfer from the argparse class into the `configuration` module, and everything else just uses that.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do we not want to have an "options" global variable in this module that contains everything instead of having separate global variables in this file? The idea would be that you could assign directly when parsing arguments:<br>
<br>
(configuration.options, args) = parser.parse_args(sys.argv[1:])<br>
<br>
Its OK if we don't do this, but this is what I was originally thinking. Then we don't need to do any transfer out of the options dictionary that is returned by the option parser. The drawback with this approach is the "configuration.options" would probably need to be initialized in case someone tries to access the "configuration.options" without first parsing arguments. So in that respect the global approach is nicer.<br>
<br>
Greg<br>
<br>
> On Dec 8, 2015, at 10:45 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Hi Greg,<br>
><br>
> Take a look at dotest.py next time you get some free time and let me know what you think.  There should be no more globals.  Everything that used to be a global is now stored in its own module `configuration.py`, and everything in `configuration.py` can be referenced from everywhere in the entire test suite.<br>
><br>
> On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
> Zach, I would also like to get rid of all global variables in the process of this change. The history goes like this: a long time ago someone wrote the initial dotest.py and parsed the options manually and stored results in global variables. Later, someone converted the options over to use a python library to parse the options, but we mostly copied the options from the options dictionary over into the globals and still use the globals all over the code. It would be great if we had at most one global variable that is something like "g_options" and anyone that was using any global variables will switch over to use the "g_options.XXXX" instead. Then we don't have to make copies and we can let the g_options contain all settings that are required.<br>
><br>
> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > I would like to do a complete audit of dotest's command line options, find out who's using what, and then potentially delete anything that isn't being used.  There's a mess of command line options in use, to the point that it's often hard to find free letters to use for new options.<br>
> ><br>
> > I created this spreadsheet with a complete list of command line options, their descriptions, and a place for people to enter what options they're using or do not want to be deleted.<br>
> ><br>
> > <a href="https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing</a><br>
> ><br>
> > If someone has already written YES in the box that indicates they need the option, please don't overwrite it.  If you write YES in a box, please provide at least a small rationale for why this option is useful to you.  Feel free to add additional rationale if someone has already added some rationale.<br>
> ><br>
> > I'm going to have a couple days in mid-December and do this cleanup, so I'd like to get a solid picture of what options are not needed before then.  After people have had some time to look over this, I'll go through the results and decide what to do with each one, and then send out another email with a proposed action column for each command line option.<br>
> ><br>
> > Please do take the time to have a look at this, because any option that doesn't have a YES in it after a couple of weeks I'm going to assume is a candidate for deletion.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
><br>
<br>
</blockquote></div>