Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing references to identifiers staticcrt and native in vcpkg/triplets/** #21768

Closed
Balnian opened this issue Nov 30, 2021 · 6 comments
Closed
Assignees
Labels
requires:more-information This Issue requires more information to solve

Comments

@Balnian
Copy link
Contributor

Balnian commented Nov 30, 2021

Hi,
I'm the maintainer for vcpkgx.com and recently I've found that both the native and staticcrt identifiers are never referenced in the triplets folder.

I'll be fair by acknowledging that native is at least kind of documented in the predefined identifier expression in the supports section of the manifest documentation
But staticcrt is nowhere to be found.

Is your feature request related to a problem? Please describe.
It's a problem for external tools makers because the triplets folder is the only reliable source for what kind of identifiers can be expected in the supports field of a manifest. This force community tool maintainers to keep hardcoded "patch" to allow complete evaluation of a supports field in a manifest like in this exemple

Proposed solution
If possible can stubs of empty cmake files be created under the triplets/** containing the missing identifiers. But even now I'm not convinced that this is the best solution. (Consider this an open discussion.)

Describe alternatives you've considered
That an index could be maintained/generated somewhere in the repo?
But this solution doesn't sound right, because it's not something that should exist in the vcpkg repo, all this data should be derivable from the repo existing data (used for normal vcpkg operation).

Additional context
Nope, everything is at the beginning of the issue.

@JackBoosY
Copy link
Contributor

Hmm... @BillyONeal can you please take a look?

Thanks.

@BillyONeal
Copy link
Member

I'm not sure I understand what you mean by a triplet 'containing' the missing identifiers. The triplets don't contain the other identifiers either; they are synthesized from things vcpkg detects from the build environment most of the time, over here: https://github.com/microsoft/vcpkg-tool/blob/1b7edfa7196228006613d96657492e78d3e22043/src/vcpkg/platform-expression.cpp#L43

staticcrt should be on for x64-windows-static, for example (it builds with /MT and /MTd)

@JackBoosY JackBoosY added the requires:more-information This Issue requires more information to solve label Dec 3, 2021
@Balnian
Copy link
Contributor Author

Balnian commented Dec 9, 2021

To be more precise is that I'm parsing the name of all the cmake files under triplets/** because it's the closest thing to having a full list of identifiers used in the supports field and that can be programmatically scraped (for many reasons I would like to avoid parsing a C++ file to get the identifiers).

Just to help me understand how these identifiers can change in the future, lets say I add under triplets/community a file for the RISC-V architecture for linux aka riscv-linux.cmake and in a package I add "supports": "riscv" would I need in the same PR to modify https://github.com/microsoft/vcpkg-tool/blob/1b7edfa7196228006613d96657492e78d3e22043/src/vcpkg/platform-expression.cpp#L43
to add the identifier riscv or would it be ok to just be treated as an invalid identifier https://github.com/microsoft/vcpkg-tool/blob/1b7edfa7196228006613d96657492e78d3e22043/src/vcpkg/platform-expression.cpp#L18?

Also it seams I've taken a shortcut in how I evaluate the supports field by using python eval (why I need all the Identifiers) (relevant links: status parser, evalEBNF)

So if I rephrase everything, I would like to know where I could get a complete list of all identifiers that can be used in the supports field that can be easily scraped for third party tooling (which the triplets folder is currently the best source from my understanding)

@BillyONeal
Copy link
Member

To be more precise is that I'm parsing the name of all the cmake files under triplets/** because it's the closest thing to having a full list of identifiers used in the supports field and that can be programmatically scraped (for many reasons I would like to avoid parsing a C++ file to get the identifiers).

OK, so you're assuming that you can take all the triplet names, separate by -s, and the resulting names will be all the identifiers? That's not generally going to be true and for things like staticcrt and native, cannot be true. You can't have a native "triplet" because whether it's native or not is a property of the "powers combined" of the host system and the triplet. You might be able to theoretically have a staticcrt one but I'm not sure what that even means generally.

In general, the set of identifiers is open ended and is going to increase over time. Moreover, we are likely to extend it to allow users to pass in whatever they want there.

arm32 also doesn't have an associated triplet name.

Also it seams I've taken a shortcut in how I evaluate the supports field by using python eval

That is likely to break soon as we added support for CSS media query syntax for consistency with the ISO SBOM standards (ISO/IEC 5926:2021). microsoft/vcpkg-tool#267

So if I rephrase everything, I would like to know where I could get a complete list of all identifiers that can be used in the supports field that can be easily scraped for third party tooling (which the triplets folder is currently the best source from my understanding)

A complete list is not possible, because the set is arbitrarily extendable by users. However, the authority of the complete list of ones the tool will cough up on its own is currently platform-expression.cpp. We can certainly make a separate doc or something for you?

@BillyONeal
Copy link
Member

Also, can you back up a bit and describe why you want to evaluate these anyway? Perhaps we could just give you a command that dumps out a report with the information you need

@JonLiu1993
Copy link
Member

@Balnian ,Thanks for posting this issue. Please reopen this issue if it still be a problem for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
requires:more-information This Issue requires more information to solve
Projects
None yet
Development

No branches or pull requests

4 participants