-
-
Notifications
You must be signed in to change notification settings - Fork 607
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
[RFC] build.d: Use JSON output to detect host compiler #11639
Conversation
Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#11639" |
Why not use Example: https://run.dlang.io/is/rmiPI1 It has been introduced in 2.079.0 (https://dlang.org/changelog/2.079.0.html#json_includes). edit: GDC doesn't implement it (yet), but you can just fallback to the most conservative settings for gdc. |
8653a7b
to
4697296
Compare
Didn't think about the JSON output. But 2.079.0 doesn't list the vendor (e.g. from the auto-tester):
So this would require executing |
Yeah, it looks like this was only added in 2.080: 2.079.1 Success with output:
2.080.1 Success with output:
However, can't we simply fallback to DMD? Another alternative would be to look at the ldc2 -Xi=compilerInfo -Xf=-
{
"compilerInfo" : {
"binary" : "/home/seb/dlang/ldc-1.9.0/bin/ldc2",
"version" : "v2.079.1",
"supportsIncludeImports" : true
}
} (though we would need to check for
A more complex alternative would be to store the output of these two host compiler invocations in Anyhow, I think falling back to |
src/build.d
Outdated
env["HOST_DMD_KIND"] = "gdc"; | ||
env["HOST_DMD_VERSION"] = "v2.079"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically GDC only ships a Phobos/Druntime of version 2.076.
Good to know, thought that applied to all compilers with a sufficient frontend version.
Implemented a small experiment which should work.
|
src/build.d
Outdated
"LDC": "ldc", | ||
"GNU D": "gdc" | ||
][get(`vendor`)]; | ||
env["HOST_DMD_VERSION"] = get(`version`)[1 .. "vX.XXX.X".length]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So apparently in the conversion to D strings it was unnoticed that _version
gets converted into a null-terminated string.
Details: #11640
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, "version" : "v2.093.1-dirty\u0000"
isn't right.
Less brittle than parsing the output of --version (especially to determine the frontend version)
ef78291
to
d253fe7
Compare
BTW I just saw that there's another Lines 1124 to 1128 in d253fe7
Maybe we should cache the output of |
[Another simple variant which works for all host compilers would be parsing the integer output of |
Definitly |
That was the initial implementation but @wilzbach suggested using the JSON output instead (which initially looked quite simple but has grown quite large to deal with older compilers). Currently leaning more to the initial approach even if it might be slower... |
I just merged this one as it is green and hopefully more future-proof approach as |
Fair enough |
I guess I should add support for -Xi then, however the implementation in json.d is naff so blocked until that is fixed. But as I see gdc is special cased that lessens the incentive to do something about it... :-) |
Well, dub (and other build tools) are supposed to use this API as well and at least for dub we will add support for this soon, so there still would be a reason ;-) |
That still doesn't stop -Xi from being utterly unusable. I count at least 1 bug in every 6 lines of that highlighted section. |
Well, maybe open an issue about it at least, so that it's not forgotten? |
I raised issues on the 2019-06-30, they still got forgotten. :-) |
Less brittle than parsing the output of
--version
(especially to determine the frontend version)
Idea inspired by #11638 which requires compiling with
-ignore
for older host compilers.