Use an object for option keys

[dcbaker]

This series introduces a new OptionKey type, which is a bit like a NamedTuple, but with some nice helper methods. The class itself is immutable (or, at least as immutable as a tuple), pickleable, sortable, and comparable. It stores 5 public traits: the name, the target machine, the subproject, the language (if it's a compiler option), and the type (project, base, builtin, compiler, etc). The thing that makes it super nice to work with the the evolve() method, which takes an existing OptionKey, and creates a new copy with specific fields overwritten in the copy, ala:

a = OptionKey('default_library', subproject='')
b = a.evolve(subproject='sub1')

It has a few convenience methods for common cases like:

a.as_root() == a.evolve(subproject='')
a.as_build() == a.evolve(machine=MachineChoice.BUILD)

It also provides a from_string() alternative constructor, which is parses command line string format, and creates an OptionKey:

a = OptionKey.from_string('foo:build.c_std')  # I might have the foo and build backwards here
assert a.name == std
assert a.subproject == foo
assert a.machine is MachineChoice.BUILD
assert a.lang == 'c'

Equally importantly, it provides a way back to the string form by converting it to a string:

a = OptionKey('std', subproject='foo', machine=MachineChoice.BUILD, lang='c')
str(a) == 'foo:build.c_std'

It also stores it's hash privately (which is safe to do because it's immutable), which makes it very fast to find in dictionaries or hashes.

There is a lot of code churn here, but there's also a lot of really ugly code that goes away as a result, no need for the code that walks over all of the different option dictionaries to figure out where an option is. Nor do we need all of the crazy code to reconstruct the string form from the internal form, and it centralizes the string -> class conversion code in a single place. We also get away from "stringly" typing.

I'm expecting a few failures in CI still (particularly on windows as I haven't run the VS backend yet).

[lgtm-com]

This pull request introduces 7 alerts when merging 6efed37 into e828c67 - view on LGTM.com

new alerts:

• 4 for Unused import
• 1 for Unused local variable
• 1 for Incomplete ordering
• 1 for Module is imported with 'import' and 'import from'

[lgtm-com]

This pull request introduces 1 alert when merging dee56b4 into e828c67 - view on LGTM.com

new alerts:

• 1 for Unused import

[jpakkane]

Traceback (most recent call last):
  File "D:\a\1\s\mesonbuild\mesonmain.py", line 132, in run
    return options.run_func(options)
  File "D:\a\1\s\mesonbuild\msetup.py", line 275, in run
    app.generate()
  File "D:\a\1\s\mesonbuild\msetup.py", line 183, in generate
    self._generate(env)
  File "D:\a\1\s\mesonbuild\msetup.py", line 245, in _generate
    intr.backend.generate()
  File "D:\a\1\s\mesonbuild\backend\ninjabackend.py", line 534, in generate
    self.generate_target(t)
  File "D:\a\1\s\mesonbuild\backend\ninjabackend.py", line 864, in generate_target
    o, s = self.generate_single_compile(target, src, False, [], header_deps)
  File "D:\a\1\s\mesonbuild\backend\ninjabackend.py", line 2559, in generate_single_compile
    self.add_dependency_scanner_entries_to_element(target, compiler, element)
  File "D:\a\1\s\mesonbuild\backend\ninjabackend.py", line 2566, in add_dependency_scanner_entries_to_element
    if not self.should_use_dyndeps_for_target(target):
  File "D:\a\1\s\mesonbuild\backend\ninjabackend.py", line 897, in should_use_dyndeps_for_target
    if self.environment.coredata.compiler_options[target.for_machine]['cpp']['std'] != 'c++latest':
AttributeError: 'CoreData' object has no attribute 'compiler_options'

This seems to be in the new C++ module scanner code that is only exercised under Visual Studio 2019 preview.

[dcbaker]

@jpakkane: fixed. Just cygwin failing because pip isn't getting installed.