[PATCH] D140959: RFC: Multilib prototype

[Michael Platings via Phabricator via cfe-commits]

michaelplatings added a comment.

A constraint is that the user should be able to choose the library with a single list of arguments, as displayed with `-print-multi-lib`. Therefore I'm sceptical about making the selection mechanism too expressive, because `-print-multi-lib` can't explain that to the user. Already the presence of negation is stretching that.

Nevertheless let's pick an example of something that can't be directly expressed in the prototype: `NOT (a AND b)`. (I don't know why you'd want to do that, if you have a motivating example of something genuinely useful then that would be better)

The expression can be rearranged to `(a AND NOT b) OR (b AND NOT a) OR ((NOT a) AND NOT b)` which can be represented in an ugly way:

  variants:
  - path: p
    args: [-a]
    attrs: [a, not-b]
  - path: p
    args: [-b]
    attrs: [not-a, b]
  - path: p
    args: []
    attrs: [not-a, not-b]
  arguments:
  - regex: -a
    matchAttrs: [a]
    noMatchAttrs: [not-a]
  - regex: -b
    matchAttrs: [b]
    noMatchAttrs: [not-b]

I think this fits with the spirit of "Make the easy things easy, and the hard things possible."

> perhaps it's enough to just make sure there's extension room in the syntax so that this can be added later

One of the many nice things about JSON & YAML is it gives you loads of room for extension, so yes. For example, currently `attrs` must be an array, but the option could be added later that it could be an object like `attrs: {not: [a, b]}`. But I hope it doesn't prove necessary ;)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140959/new/

https://reviews.llvm.org/D140959