michaelplatings added a comment. > Could be worth adding a design principles section at the end
That was a very helpful suggestion, thank you. Writing them out helped me examine the compatibility story more carefully. Consequently I added a requirement for a "minimumClangVersion" property, although I haven't implemented that in the other patches yet. > May be worth a quick description of how we might model some awkward cases Not done yet. This certainly can be modelled but I agree an example would be helpful to provide. ================ Comment at: clang/docs/Multilib.rst:105 + +This decision is hard-coded per ToolChain subclass. + ---------------- peter.smith wrote: > Considering the BareMetal ToolChain is used by RISC-V, Arm and AArch64 is > there scope for a different choice per toolchain. I guess that we could put a > predicate function for the ToolChain that could change due to architecture. For the BareMetal ToolChain the only one RISC-V multilibs can ever match a given set of command line options so this isn't a problem in practice. ================ Comment at: clang/docs/Multilib.rst:122 +``-fno-exceptions`` multilib variant need only contain C++ libraries. + +Stability ---------------- peter.smith wrote: > Although it can be worked out by looking at the example, which I think is > your intention from the comment. It may be worth a section on Syntax that > extracts some of these. > ``` > Syntax of multilib.yaml > =============== > ``` > Some suggestions/questions: > * Does the file have to contain both variants: and flagmap: are either of > them optional? > * Do variants have to come before flagmap, or is order not important. > * Will be worth highlighting that the order of the variants may be > significant depending on the toolchain. > * Each variant is made up of dir: (path added to sysroot?), flags: [comma > separated list of flags] and printArgs: [comma separated list of command line > options for -print-multi-lib and -print-multi-directory, but not important > for multilib selection] > * Each flagmap is made up of a POSIX extended syntax regex: that matches a > flag, and (one of?) matchFlags/noMatchFlags which either adds or removes > respecively a [comma separated list of flags] I opted to keep the spec, such as it is, in the example, but I've expanded it to answer your questions, unless it's implicit in it being YAML (e.g. lists //can// be comma separated but there are other ways to express them in YAML). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143587/new/ https://reviews.llvm.org/D143587 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
