RFC: Tool Introspection #2
Conversation
Initial, ported from wg21 source, wording for ecostd/rfcs#2
There was a problem hiding this comment.
Overall a good amount of info, but there are serious issues with:
- the use of asciidoc over more well known formats such as markdown for the actual proposal
- We should lean more heavily on prior art from other languages, as the future of C++ tooling is tied entirely to "having tools and languages talk to each other regardless of why they want to"
| `.stdinfo` text. For example: `cl.exe` => `cl.stdinfo`, or | ||
| `pass:[g++]` => `pass:[g++].stdinfo`. |
There was a problem hiding this comment.
I'm very much of the opinion that we should keep .exe in the name on Windows. It is possible to treat multiple file extensions as executables via COMSPEC and the windows registry (this is why .pyw files can be double clicked and run like any executable). Keeping the file extension for everything but .exe comes off as requiring an extra step for this one specific behavior.
There was a problem hiding this comment.
Is the suggestion to uniformly just add .stdinfo to the tool name? I.e. The following?
tool.exe==>tool.exe.stdinfotool.sh==>tool.sh.stdinfotool.bat==>tool.bat.stdinfo
I like the idea as it's just simpler to explain. And likely easier to implement for everyone. And that's regardless of the exec thing.
| 2. The introspection file can be found: in the same filesystem location | ||
| as the tool executable (or script, or equivalent), in an implementation defined | ||
| location relative to the tool location, or in an implementation defined global | ||
| location (i.e. an absolute path location). |
There was a problem hiding this comment.
This should have a sublist so it is obvious which is used.
| 2. The introspection file can be found: in the same filesystem location | |
| as the tool executable (or script, or equivalent), in an implementation defined | |
| location relative to the tool location, or in an implementation defined global | |
| location (i.e. an absolute path location). | |
| 2. The introspection file can be found: | |
| .. in the same filesystem location as the tool executable (or script, or equivalent) | |
| .. in an implementation defined location relative to the tool location | |
| .. in an implementation defined global location (i.e. an absolute path location) |
Furthermore not having a central location as defined by at least an environment variable separate from the implementation is not going to turn out well. Developers will always want to override or provide information on a tool themselves and having a central location like e.g., pkg-config is worthwhile.
| interface. This can include any single interface, like a single target tool | ||
| option. Or it can include a collective interface of the target tool that covers | ||
| many options. A capability is specified as a series of "scoped" identifiers | ||
| separated by underscore ("_"). The capability must match this regular expression: |
There was a problem hiding this comment.
There is plenty of reasoning in this section for the rest of the regex, however there is nothing to explain why _ is preferred over - or : or even an ascii C0 control code.
| applications that want custom capabilities to create alternate names has | ||
| various drawbacks, yes, we should accept numbers in the names. | ||
|
|
||
| === Version Specification |
There was a problem hiding this comment.
The version specification does not take so-called "epochs" into account. These are specified in tools such as RPM and apt-get, and in packaging specifications such as PEP440.
| include::example-07.json[] | ||
| ---- | ||
|
|
||
| === Version Matching |
There was a problem hiding this comment.
The RPM, PEP440, and Debian folks have all done work in this space. We should look at and reference their pre-existing work.
If the concern here is "how do we handle ranges and compatibility?" that is not our job, and there are solutions for it such as pubgrub, which has been adopted by Dart.
Using "core" is clear, short, and avoids using an abbreviation.
This presents a way for tools to both describe what they can do, and for tools to adhere to what users ask them to do. And do it in a way that is future proof.
preview
wording